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

Our security team has audited a lot of WordPress sites for UK SMEs, and the findings are fairly consistent. Five common vulnerabilities account for a large proportion of the exposures we find, and each one typically takes a few hours of skilled time to fix. We go through each one below, with why it matters and what the remediation involves.

 

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.

An unpatched plugin with a critical vulnerability is often exploited within 48 hours of the CVE being published. With so little time between “patch available” and “site compromised”, ad-hoc monthly updates are usually not fast enough. Start by applying all outstanding plugin updates, then agree a written update policy for the future. 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 with no policy at all are already falling behind. 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

Many of the sites we audit have at least one admin account without MFA, and about a third have no MFA at all. Most SME admin passwords have turned up in at least one credential dump by now (HaveIBeenPwned lists over 12 billion breached passwords), so this is the second-highest risk category in most of our audits.

A brute-force attack against wp-login.php from a single IP can attempt hundreds of guesses per minute, and if the password is on a dump list, the guess tends to succeed quickly. MFA stops that attack even when the password itself has been compromised. Enforce MFA on every admin, editor and author account, whether through WordFence, iThemes Security or a dedicated MFA plugin. Setup typically takes under two minutes per account.

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) get through to the site, and the only defence left is whatever the plugins themselves provide. Security headers protect against related attacks such as clickjacking and cross-site scripting. To fix both, enable Cloudflare’s free WAF or WordFence’s built-in firewall in blocking mode, and 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 decides more than anything else 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.

Backups kept on the same server as the site tend to be compromised along with it, so if the server is hit by ransomware or wiped, the backup goes too. Daily off-site backups with 30-day retention usually mean you can go back to a clean copy from before the problem started. Set them up, and make sure you test a restore at least once: 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 two or more of these checks turn up a problem, 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 lists the warning behaviours to look out for.

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.