Why does this happen?
WordPress ships with settings chosen so that everything works on any host, not so that the site is as hard to attack as possible. Nothing is broken. But a few defaults give attackers a head start, and automated scanners, including the ones card processors run for PCI checks, flag every one of them.
The gaps we find most often, in order:
- XML-RPC is open. The file
xmlrpc.phpis an older way for apps to talk to WordPress. It is switched on by default and accepts usernames and passwords, so bots use it to guess logins in bulk. - Usernames are easy to find. Author archive links and the public user list in the REST API can reveal the names people log in with. That hands an attacker half of every login.
- Files that should be private can be downloaded. A debug log left switched on, a backup copy of
wp-config.php, an.envfile or a.gitfolder can expose database passwords and file paths. Folder listings in uploads show every file you have. - Security headers are missing. WordPress only sends a few of these on its own login and admin screens. Headers such as Strict-Transport-Security and X-Content-Type-Options have to be added at the server.
- Logins are lightly guarded. Core has no two-factor login and no limit on failed attempts.
- Too many people are administrators. Old staff, agencies and developers keep full access long after they need it, and any administrator can edit plugin and theme code from the dashboard.
On a WooCommerce store this matters more, because the same site handles customer accounts and payments, and a failed PCI scan can put your card processing at risk.
Try this first
These checks are safe on a live site. The only changes they ask for are to accounts and sign-up settings you control.
- Review your administrators. Go to Users, All Users and filter by Administrator. For anyone who no longer needs full access, edit the user and change their role, for example to Editor, or to Shop Manager on WooCommerce. Change the role rather than delete the account, so the content they wrote stays attached to them. Before you change a role, check the account is not the one a connected service logs in with, such as stock sync, accounting or a till system. On WooCommerce, WooCommerce, Settings, Advanced, REST API shows which user each key belongs to. If you are not sure, leave that account for us. Never demote your own account. If you see an administrator nobody recognises, stop here and read the hacked site section below.
- Check who can sign up. Go to Settings, General. Under Membership, “Anyone can register” should only be ticked if you need it, and New User Default Role should never be Administrator. On WooCommerce, customer sign-up is controlled by WooCommerce’s own settings, so this box does not stop customers creating accounts at checkout.
- Sign out old sessions. Go to Users, Profile and use “Log Out Everywhere Else” if it is available. For other administrators, open each one in Users, All Users and use “Log Out Everywhere” on their screen. Look at Application Passwords on your profile and on each administrator’s screen, and write down any you do not recognise. Ask whoever set up your integrations before you revoke one, because a connected service may depend on it.
- Read Site Health. Go to Tools, Site Health. Items marked Security are worth a look, such as “Your site is set to log errors to a potentially public file”. Write them down rather than changing settings yourself.
Then hand it over. Blocking XML-RPC, adding headers, blocking files and turning off the file editors all happen in server rules or wp-config.php. One typo there can take the whole site down, and a header that is too strict can stop card fields from loading at checkout.
What does a security scan actually check?
Most scanners, including PCI scans, look at your site from the outside, the same way an attacker does. They request xmlrpc.php, try to look up usernames, ask for well-known private files and read the headers your server sends. Our free WordPress audit runs the same kind of checks and lists each gap it finds. Some findings are noise, such as WooCommerce cart cookies that are meant to be read by JavaScript. Others, such as a downloadable debug log, need fixing straight away. Part of the job is telling them apart and writing that down for your scan vendor.
What if my site has already been hacked?
Then hardening comes second. An administrator nobody created, files you did not change or spam pages in Google mean someone is already inside, and locking the doors does not remove them. Start with our hacked site cleanup. For what a break-in really costs a small business, read the real cost of a hacked WordPress site.
Hardening also works best on a site that is up to date. If plugins or WordPress itself are far behind, see our update catch-up. Hardening closes the gaps you have today; BoltPress Security, included in every care plan, then watches for new ones, with a daily check of your plugins, theme, WordPress and PHP version against known security problems. If your scan flagged certificate or “not secure” warnings, see the SSL and mixed content fix. For everything else, browse the Fix WordPress page.