The 5 Most Common WordPress Vulnerabilities Found in UK SME Security Audits

Our security team has audited many WordPress sites for UK SMEs, and the pattern that emerges is fairly consistent. The five common vulnerabilities account for a large proportion of the exposures we find, and each has a fix that typically takes a few hours of skilled time to apply. This guide names each of the five, explains why it matters, and walks through the remediation.

 

Vulnerability 1: Outdated plugins

Outdated plugins are by a clear margin the most common finding. WordPress plugins are the single largest attack surface on the platform, and most compromises trace back to a plugin that was left unpatched for months after the patch was released. Attackers do not need to discover new vulnerabilities in this case; they simply scan for sites still running the old version of a plugin with a publicly known exploit.

This matters because an unpatched plugin with a critical vulnerability is often exploited within 48 hours of the CVE being published, and the window between “patch available” and “site compromised” is small enough that ad-hoc monthly updates are usually not fast enough. The fix is to apply all plugin updates and then set a written policy going forward. For business-critical sites we tend to recommend automated updates for security patches (with a rollback path in place) and reviewed updates for minor and major versions; sites without any such policy are already behind the curve. Our guide to patching a critical WordPress vulnerability without downtime walks through the process for high-priority updates.

Vulnerability 2: Missing or weak multi-factor authentication

A common recurrence with sites we audit have at least one admin account without MFA, and about a third have no MFA at all. Given that most SME admin passwords have been included in at least one credential dump at this point (HaveIBeenPwned lists over 12 billion breached passwords), this comes out as the second-highest risk category in most audits.

The reason it matters is that a brute-force attack against wp-login.php from a single IP can attempt hundreds of guesses per minute, and if the password is in a dump list, the guess tends to succeed quickly. MFA breaks that attack path even when the password itself is compromised. The fix is to enforce MFA on every admin, editor and author account, whether via WordFence, iThemes Security or a dedicated MFA plugin; setup time per account is typically under two minutes.

Vulnerability 3: No Web Application Firewall or missing security headers

A large number of sites we audit had no WAF at all, and many of the sites that did have a WAF had it running in monitor mode rather than blocking mode, which does not actually stop anything. Alongside this, the basic set of security headers (HSTS, Content Security Policy, X-Frame-Options) was commonly missing.

This matters because a WAF filters out the majority of automated attack traffic before it reaches WordPress itself. Without one, even trivial attacks (SQL injection attempts, cross-site scripting probes) reach the site and rely on the plugins themselves to defend against them. Security headers protect against related attacks such as clickjacking and cross-site scripting. The fix is to enable Cloudflare’s free WAF or WordFence’s built-in firewall in blocking mode, and to add the standard set of security headers either via a plugin or in .htaccess.

Vulnerability 4: xmlrpc.php exposed

We audit a lot of websites that still have xmlrpc.php exposed to the internet. This is a legacy WordPress endpoint that is very rarely needed on a modern site but is heavily abused by attackers, both for brute-forcing passwords at scale (it accepts multiple login attempts per request, which lets attackers try thousands of passwords per second without triggering the usual rate limits) and as a vector for pingback DDoS attacks that use your site to attack others.

The fix is to block xmlrpc.php in .htaccess or via a security plugin. Almost no modern SME needs it enabled, and the practical test is to turn it off and check whether anything breaks over the following week; if nothing does, it is safe to leave off permanently.

Vulnerability 5: Backup gaps

This is not strictly a “vulnerability” in the classic sense, but it is the largest single determinant of what happens next when something else does fail. Sites without off-site backups have no meaningful recovery option after a compromise or a serious plugin failure.

The reason it matters is that backups stored on the same server as the site tend to be compromised alongside the site, so if the server is hit by ransomware or wiped, the backup goes with it. Off-site backups with 30-day retention are usually the difference between an incident and a disaster. The fix is to set up daily off-site backups with 30-day retention and, importantly, to test a restore at least once, because roughly one in five backup setups we test does not restore cleanly on the first attempt.

How to audit your own site in 30 minutes

You can check most of the above yourself in about half an hour by working through the following in order:

1. Log into wp-admin and check Dashboard → Updates. Anything red or yellow counts as a finding.
2. Check Users → All Users. Any admin without MFA is a finding.
3. Check whether the site has a WAF, either Cloudflare in front or WordFence firewall enabled in blocking mode.
4. Test whether xmlrpc.php is exposed by visiting yourdomain.com/xmlrpc.php in a browser; if it returns “XML-RPC server accepts POST requests only”, it is exposed.
5. Confirm that your last successful backup is under 24 hours old, off-site, and that you can identify how to restore it.

If issues surface on two or more of the above, the site is materially more exposed than it should be. Our full WordPress security checklist covers the remediation steps in more detail, and the signs your website is about to be hacked article helps flag warning behaviours before they become incidents.

The WordPress security audit and remediation case study describes a UK client where the audit surfaced a critical, publicly-known plugin vulnerability that had been present for months and was already being probed. Full remediation was completed with no site downtime.