WordPress exposure checker

The login page: a request to see whether it is served at the default path. Nothing is posted, no username is tried, and no login is attempted.

The REST API index: a request to the public index to see whether it answers. Only the public index is read, and no authenticated route is called.

The XML-RPC endpoint: a plain GET, to see whether the file responds. No XML-RPC method is ever invoked.

Configuration and debug paths: a defensive check for files that should never be served — a configuration file, a backup copy, a debug log. Contents are never stored or shown, only the fact that the path answered.

A login page at the default path is normal. It is also the first thing credential-stuffing traffic tries, which is an argument for rate limiting and two-factor authentication rather than for moving it.

A reachable REST API index is normal too, and by design on most installations. Knowing it answers is what lets you decide whether any of its public routes need restricting.

A responding XML-RPC endpoint is a normal WordPress endpoint, not a vulnerability. It widens the surface, and if no client needs it — no remote publishing, no mobile app, no connected service — it can be turned off.

A served configuration, backup or debug file is the one finding on this page that is serious on its own, and it is serious immediately.

A WordPress configuration file contains the database credentials and the authentication salts. Anything that can read it has both.

Removing the file from the web root is the first step and it is not the last one. Every credential it contained has to be rotated, because you cannot know from the outside how long the path was answering.

The same applies to a backup copy of it, which is how this usually happens — an editor leaving a file with a backup suffix that the server no longer recognises as one to execute, and therefore serves as text.

A debug log belongs in the same category for a different reason: it accumulates whatever the application wrote while something was going wrong, which is frequently more than anyone intended to keep.

No credentials are submitted anywhere, so nothing behind the login is examined.

No path enumeration. A fixed set of conventional paths is requested; there is no wordlist and no generated path, so absence is not proof of absence.

Nothing found is exploited, downloaded or reproduced in the report. A served file is reported as a served path.

A path that answers 403 is recorded as refused. Whether that refusal comes from the server, a plugin or a protection layer is not distinguishable from outside.

`wordpress.login` checks whether the login page is served. `wordpress.rest_api` checks whether the public REST index answers. `wordpress.xmlrpc` checks whether the XML-RPC file responds to a plain GET.

`wordpress.config_exposure` is the defensive check for accidentally served configuration, backup or debug files.

`wordpress.detected` establishes that the site is WordPress in the first place, from the signals the profile detector already collected — the checks above run only when it does.