What we found scanning 99 real WordPress sites

Site Doctor checks a little under a hundred live WordPress sites for us every day. Dental offices, a couple of law firms, a publisher, some remodeling companies. Boring sites, mostly. The kind nobody thinks about until something breaks.

So last week I pulled the latest scan for all of them into one place to see what the pile actually looked like. I expected the usual outdated-plugin noise. A few things surprised me.

Here’s the short version: 62% were missing security headers, 37% were running a plugin, theme, or core with a known CVE, and three of them were serving a script that quietly shipped data off the page. That last one is a card skimmer, and nobody who owned those three sites had any idea.

None of this came from logging into anything. Site Doctor looks at each site from the outside, in a real browser, with a read-only connector that can’t touch a single file. So this is what a visitor’s browser sees — not what a plugin running on the server reports back.

The raw numbers

What we saw	Sites	Out of 99
Missing at least one security header	61	62%
Pulling content from third-party hosts (1 to 11 of them)	78	79%
Running something with a known vulnerability	37	37%
A hidden or cross-origin iframe on the page	11	11%
An obfuscated script exfiltrating data (skimmer)	3	3%

Security headers: the free thing almost nobody does

62% missing at least one. The most common case wasn’t one header missing — it was five at once, on 29 sites. These are the response headers that tell a browser not to let your page be framed, not to guess content types, not to load mixed content: Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Strict-Transport-Security.

They cost nothing. You add them once and forget them. And two thirds of real, maintained business sites just don’t have them, because nothing visibly breaks when they’re absent. That’s the trap with headers — the day they matter is the day you already needed them.

The vulnerable stuff was mainstream

I keep expecting the vulnerable 37% to be running some abandoned plugin from 2019. It almost never is. The repeat names were the ones everybody uses: a critical bug in the Astra theme, a couple of Elementor CVEs, four known issues in Divi, and a few sites sitting on a core with more than a dozen unpatched advisories.

Add it up across those 37 sites and you get 39 critical and 40 warning-level findings. These aren’t exotic. They’re the default stack of a modern WordPress build, left one or two updates behind.

The three that keep me up

Three sites were running an obfuscated inline script that sends data out. On a site that takes payments, that is a breach happening right now, in front of every customer at checkout.

Here’s why it matters that we caught it from the outside: a server-side scanner reads files and database rows. This code never lives in a file the scanner reads — it runs in the visitor’s browser, injected into the rendered page. So the plugin says “clean” and means it, while the page robs people. We took one of these apart a while back if you want to see the guts of one.

If you maintain WordPress, do these three things

Check your response headers. Audit every plugin and theme against a current CVE list, not just the “update available” badge. And look at what actually runs in the rendered page, not only what sits on disk. Those three cover most of what showed up here.

That’s the whole job Site Doctor does, read-only, and it hands the list back sorted by what’ll bite you first. But you can start with curl and your browser’s network tab this afternoon — the point isn’t the tool, it’s that almost nobody looks.