What an external WordPress scan can see — and what it cannot

Most WordPress risk is inside the application: which plugins and versions you are running, whether a known vulnerability in one of them is reachable on your installation, what your theme does with input. None of that is visible to a scanner that arrives from outside, is not authenticated, and never signs in.

So this is not a WordPress vulnerability scanner, and it will not tell you to update anything. It checks the parts of WordPress's external posture that are exposed by configuration rather than by a code flaw — and which, across a large installed base, are exposed often enough to be worth a scan.

If what you need is "which of my plugins has a known CVE and is my install reachable through it", that requires authenticated access to your own admin, which is a different tool and a different engagement.

Version disclosure CMS-001 APP-012 — whether the site publishes its exact version. A disclosed version tells somebody which vulnerabilities to try first. The finding is the disclosure, not the version number.

Account enumeration CMS-002 — whether author archives, REST responses or feeds list account names to an unauthenticated visitor. This is what turns a known admin username into a targeted credential attack rather than a guess.

Reachable admin and login CMS-008 — whether the administration login and API endpoints are reachable from outside. Necessary for the site to work; the finding is when it is reachable and the surrounding hardening is absent.

XML-RPC CMS-004 — whether it is enabled. It is a legitimate interface for the WordPress mobile app and for some publishing tools, so "enabled" is reported as an exposure to review rather than as a defect. It is also a well-known amplification and brute-force surface, which is what makes it worth a decision.

Configuration backups CMS-009 APP-008 FEX-003 — whether files such as wp-config.php backups, .env files or version-control directories are served to unauthenticated clients. This is the highest-severity finding on this page. A reachable configuration backup routinely contains database credentials and an authentication-key salt, and it is the single most common way a WordPress site is taken over without any vulnerability at all.

Directory listing CMS-005 — whether a plugin or theme directory is browsable, which publishes the exact set of extensions installed.

Debug output and logs CMS-006 FEX-005 FEX-006 — whether a debug page or a log file is served publicly. Both routinely contain absolute paths, hostnames and query data.

Installer reachability CMS-007 — whether the setup tool is still reachable. On a live site it should not be.

Fingerprinting CMS-013 — whether a CMS was identified at all, and which. Reported as an observation: it is information, not a defect, and the point of the check is that the answer should be known rather than assumed.

Every check above is part of the verified-ownership level of an assessment. A basic assessment runs on any public web address straight away, and it does not include them.

The reason is specific rather than general. Probing for an exposed wp-config.php backup, an open XML-RPC endpoint or a reachable installer is not something to do to a site that has not shown it wants to be assessed. Verification is a DNS TXT record in the domain's own authoritative zone; publishing it takes a couple of minutes and unlocks the full check surface permanently until it expires.

The methodology sets out the whole model. What the report shows, either way, is which level it ran at — so a basic report is never mistaken for a complete one.

A reachable config backup. Delete it, then rotate the credentials it contained. Deleting the file does not un-disclose a URL that was already crawled, indexed or requested — treat every secret it held as published. Then find how it was published: a deploy step copying the file into the document root is a build problem, not a server problem, and it will put it back.

Version disclosure. Usually a filter removing a generator tag. Worth doing, understood for what it is: it raises the cost of a targeted attempt, it does not remove one. Nothing about the underlying version changes.

Account enumeration. Block author archives, or make them require authentication. The side effect to expect is that anything relying on ?author= URLs will break.

XML-RPC. If nothing you use needs it, disable it. If something does — the mobile app, Jetpack, some editorial workflows — leave it on, rate-limit it at the server, and note the decision so it is a decision rather than an oversight.

Directory listing and debug output. One line of server configuration each. Both are default-off and get turned on by a debugging session that was never turned back off.