The State of WordPress Security in 2026: What 7.6 Million Live Sites Told Us

WordPress runs a large share of the web, which means the security posture of the average WordPress site is, in a real sense, a snapshot of the internet's own hygiene. So we measured it — not a survey, not a sample of volunteers, but a direct look at millions of live sites.

As of 30 July 2026, our checks cover 7,589,296 WordPress sites. Every one gets the same non-invasive external tests: which security headers it sends, whether it leaks sensitive files, whether it hands out usernames, whether there are signs of malware, and which version of WordPress core it's running.

The short version: most of what we found is widespread, boring, and well understood — which is the good news hiding inside the bad, because boring and well understood also means fast to fix. The one exception is urgent, and we cover it in detail below: a critical, unauthenticated remote-code-execution flaw in WordPress core, patched only this month, that still affects more than two million of the sites we scanned. Here's the full picture.

How we measured this

A few notes up front, because a number is only as good as its method.

• These are external, non-invasive checks. We look at what any visitor's browser already receives — response headers, publicly reachable URLs, the homepage. We don't log in, we don't exploit anything, and we don't touch anything a normal page load wouldn't.
• The denominator is 7,589,296 sites we've confirmed running WordPress, all root domains. Every figure below is out of that number unless stated.
• This is a floor, not a ceiling. Sites sitting behind a blocking WAF (Cloudflare, Wordfence, and similar) don't respond to a direct scan, so they're not in this dataset. In other words, this is the population of WordPress sites an attacker can directly probe — the sites most exposed in the first place. The true web-wide picture, including well-defended sites, is better than what follows; the picture for undefended sites is exactly this.
• Numbers shift daily as we rescan. This report is a single consistent snapshot taken on the date above.

Finding 1: Almost nobody sends security headers

Security headers are small instructions a site sends with every page telling the browser how to behave — enforce HTTPS, block clickjacking, don't sniff content types, and so on. They're free, they don't slow anything down, and they close entire categories of attack. They are also the most-ignored control in all of WordPress.

We grade each site A–F on how many of six standard headers it's missing:

• Grade A (all six present): 126,609 sites — just 1.7%
• Grade B (1 missing): 188,725 — 2.5%
• Grade C (2 missing): 267,977 — 3.5%
• Grade D (3–4 missing): 732,362 — 9.6%
• Grade F (5–6 missing): 6,273,623 — 82.7%

More than four out of five WordPress sites are missing nearly every security header. Fewer than 1 in 58 gets top marks.

Broken out by individual header, the neglect is remarkably even — no single header is the outlier; they're all simply absent:

• Content-Security-Policy — missing on 7,093,793 sites (93.5%)
• Permissions-Policy — missing on 6,705,583 (88.4%)
• Referrer-Policy — missing on 6,654,619 (87.7%)
• X-Frame-Options — missing on 6,624,789 (87.3%)
• X-Content-Type-Options — missing on 6,263,422 (82.5%)
• Strict-Transport-Security (HSTS) — missing on 5,997,772 (79.0%)

Content-Security-Policy is the hardest of the six to configure, so its near-total absence is at least understandable. The rest are one-line, set-and-forget headers with no downside — and they're missing from the overwhelming majority of sites purely because no one added them. (We break down all six, with copy-paste config, in our guide to WordPress security headers.)

Finding 2: 96% use HTTPS — but only 1 in 5 enforces it

Here's a number that surprised us. 7,273,900 sites (96%) serve their site over HTTPS. The SSL-certificate battle is essentially won; free certificates and one-click hosting toggles did their job.

And yet only about 21% of sites send an HSTS header — the one line that tells browsers to require HTTPS and refuse to silently downgrade to unencrypted HTTP.

96% of WordPress sites bought the lock. Only 1 in 5 actually turns the key.

Without HSTS, a visitor's very first request can still be intercepted and downgraded before the certificate ever comes into play. Almost every site in our dataset has done the hard part (getting a certificate) and skipped the trivial part (enforcing it). If you do one thing after reading this, add HSTS.

Finding 3: 37% of sites hand out their usernames

By default, WordPress will tell anyone who asks which usernames exist on a site — through the REST API and the ?author=1 URL pattern. An attacker who knows your usernames already has half of every login; all that's left is the password.

2,838,106 sites — 37.4% of every WordPress site we checked — leak usernames this way.

More than a third of the WordPress web gives attackers half the login for free.

This is, by a wide margin, the single most common security finding in the entire dataset — bigger than every exposed-file category combined. And it's not the result of a mistake; it's the default state, shipped and never changed. We wrote about exactly how enumeration works and how to shut it off; it's one of the highest-value, lowest-effort fixes available.

Finding 4: The files sites leave lying around

The next tier is what a penetration tester calls low-hanging fruit: files that should never be public but are. In total, 138,421 sites expose at least one sensitive file.

• phpinfo pages — 117,179 sites. A forgotten diagnostics file that publishes the server's entire PHP configuration: paths, versions, extensions, and enough environment detail to plan a targeted attack. Split by filename, it's 72,045 sites exposing phpinfo.php and 45,134 exposing info.php — the two names developers reach for out of habit and forget to delete.
• XML-RPC enabled — 13,041 sites, a classic brute-force and amplification vector.
• Directory listing — 12,134 sites serving the raw contents of folders.
• debug.log — 6,822 sites quietly publishing errors, file paths, and sometimes credentials.
• error_log — 1,873 sites.
• install.php reachable — 1,698 sites, some of which can be hijacked to repoint the site at an attacker's database.

None of these are exotic. Every one is a default left on or a temporary file never deleted — and every one is a single action to close.

Finding 5: Malware and broken installs

At the sharp end, we flagged 313 sites with active malware indicators and 17,307 sites throwing fatal PHP errors on their homepage. Fatal errors aren't a vulnerability by themselves, but they're a reliable smell of an unmaintained site — a failed update, an abandoned plugin, a version mismatch — and unmaintained is precisely the condition attackers hunt for.

Finding 6: Millions are exposed to a critical unauthenticated RCE

The most urgent finding in this whole report isn't the ancient long tail — it's the newest-looking sites.

On 17 July 2026, WordPress shipped an emergency release, 7.0.2, to patch wp2shell (CVE-2026-63030): a pre-authentication remote code execution chain built from a REST API batch-route confusion and a SQL injection (CVE-2026-60137). It needs no login, no plugins, and no special configuration — a default install answering a single anonymous HTTP request is enough, and a working proof-of-concept is already public. It affects WordPress 7.0.0–7.0.1 and 6.9.0–6.9.4, with the related SQL-injection issue also hitting the 6.8 branch. The fixes are 7.0.2, 6.9.5, and 6.8.6.

Here's the problem: those vulnerable versions are, right now, among the most common on the entire web. In our snapshot, WordPress 7.0 alone accounts for 1,162,508 sites, 7.0.1 another 538,924, and 6.9.4 a further 399,101 — before counting the rest of the vulnerable 6.9 range. Add it up and well over two million sites in our dataset are running a version exposed to unauthenticated remote code execution.

The single most common WordPress version on the web right now is one an anonymous attacker can take over with a single request.

There is good news buried here. WordPress.org pushed forced automatic updates, and you can see that machinery working: 825,332 sites are already on the fixed 7.0.2 and 85,526 on 6.9.5. But forced updates don't reach everyone — version-controlled deployments, sites with auto-updates disabled, and unusual hosting setups get left behind, and those are exactly the sites still sitting on 7.0 and 7.0.1. If you run WordPress and haven't confirmed you're on 7.0.2 / 6.9.5 / 6.8.6, stop reading and go check: with a core RCE and a public exploit, hours matter more than days.

And that's before the long tail. Separately, about 318,805 sites — one in twenty-four — are still on WordPress 4 or 5, branches years past end-of-life, each carrying its own published list of unpatched vulnerabilities. (Roughly 45% of sites don't expose a version string at all, so the true distribution is partly hidden.)

We flag vulnerable core versions directly in our listings and on every domain's detail page, so you can tell at a glance whether a site is running something exposed.

Why is it this bad?

Two reasons, and neither is exotic.

Defaults. WordPress ships permissive. Username enumeration, XML-RPC, and the absence of security headers are all default states, not decisions anyone made. The overwhelming majority of what we flag was never deliberately configured to be insecure — it was simply never configured at all.

Maintenance gaps. Most WordPress sites are built once and left to run. No one is watching for a stray phpinfo.php, a new core release, or a plugin that quietly shipped a vulnerability. The exposures accumulate not through negligence but through absence — and the popularity of a plugin is no guarantee of safety. Some of the most-installed plugins on the web (RevSlider and the WPBakery/js_composer family among them, each on hundreds of thousands of sites) have histories that include high-profile vulnerabilities. Popular means widely targeted.

The good news

Look back over everything above and notice how little of it is hard. Security headers are a few lines in a server config. Username enumeration is one setting. A leaked debug.log is one deletion. There is almost nothing in this dataset that needs a rebuild, a migration, or a specialist — it needs an afternoon and a checklist.

Here's that checklist:

1. Add the six security headers. Aim for at least a B; an A is an afternoon's work.
2. Turn on HSTS — you already have the certificate; enforce it.
3. Block username enumeration at the REST API and the ?author= redirect.
4. Delete diagnostic and leftover files — phpinfo.php, info.php, debug.log, error_log, install.php.
5. Disable XML-RPC if you don't use it, and turn off directory listing.
6. Keep core, themes, and plugins current — and remove what you don't use.
7. Put a WAF in front (Cloudflare, Wordfence, and similar). Sites behind a good WAF don't even appear in scans like ours, because they're already protected.

You can see exactly where your own site stands in about ten seconds with our free domain security check, and every fix above is spelled out step by step in our security guide. The full live picture is always on the security overview.

Methodology: external, non-invasive checks across 7,589,296 live WordPress sites, snapshot taken 30 July 2026. Sites behind a blocking WAF are not represented, so these figures describe the directly-reachable WordPress population and should be read as a floor.

TLDWP continuously scans the live WordPress web for security exposures. If you'd rather not work through the checklist yourself — or you're an agency wanting a second set of eyes across a portfolio of sites — we offer WordPress hardening and ongoing maintenance. Get in touch.