WordPress Health Checker

This check reads. It never attacks.

Every request this tool makes is an ordinary, rate-limited GET of a public URL — the same requests any visitor or search engine makes. It reads what the site publishes about itself and nothing more.

That boundary is deliberate and worth stating plainly, because a scanner that tests whether the login form is rate limited has to send repeated failed logins at somebody's production site. Our address in a client's access log would look identical to an attacker's, however good the reason. So we report that the login page is reachable, and we explicitly do not test what happens if you hammer it.

How versions are detected, and where that goes wrong

WordPress publishes its core version in a generator meta tag and in the RSS feed, unless a plugin has removed it. Plugin and theme versions come from the query string appended to their asset URLs — the familiar ?ver= on a stylesheet or script.

Two things make that noisier than it looks. First, a plugin that does not set its own version gets the WordPress core version appended instead, so a naive reader concludes that every plugin on the site shares one implausible version number. Second, many themes append a ten-digit file modification timestamp rather than a version. Both are filtered here, which means some components report no version at all — and no version is the honest answer, because a wrong version produces a wrong CVE match.

Removing the generator tag, incidentally, is not security. It changes nothing an attacker can reach and it makes your own inventory harder to keep.

The exposure checks

User enumeration. By default the REST API and the ?author= redirect will both hand out the list of usernames on a site. That is not a vulnerability on its own — it is half of a credential-stuffing attempt, and it is trivially closed.

Directory listing. A directory without an index file will, on some configurations, list its contents. Uploads directories are the common case and the contents are frequently more interesting than anyone intended.

Security headers. Missing Content-Security-Policy, X-Content-Type-Options, Referrer-Policy and Strict-Transport-Security are each a small thing, and collectively they are the difference between a bug being contained and being useful.

Reachable endpoints. xmlrpc.php and the login page being publicly reachable are facts, not findings — plenty of sites need them. They are reported so that you can decide, not so that a number goes down.

What a CVE match means and what it does not

Where a component reports a version, it is matched against the National Vulnerability Database by exact version, and any known vulnerability is listed with its severity.

Exact matching cuts both ways. It will not invent a match for a version it cannot read, which is right — but it also means "no known CVE" is a much weaker statement than it sounds. It means no published vulnerability matched the versions we could see. A component whose version is hidden, a vulnerability not yet published, or a plugin that has simply never been reviewed all produce the same clean-looking answer.

Treat a finding as a fact to act on and a clean result as an absence of evidence.

Doing this once versus continuously

A one-off scan tells you the state of a site today. The version that matters is the one running the week a vulnerability is published for a plugin you installed two years ago and have not thought about since.

On IT Watch this check runs on a schedule as part of Agency and above, alongside the certificate, domain, DNS, email authentication and reputation checks for the same site.

Common questions