Exposed WordPress endpoints

WordPress routes that answer to anyone: the users route lists every author login name, and xmlrpc.php is the endpoint password-guessing tools use because it allows many attempts per request.

• Help center

WordPress ships a few public endpoints that are convenient for integrations and equally convenient for attackers. This row appears only when SiteScan has identified the site as WordPress and at least one of them answered, so it is always a finding.

• user-enumeration — /wp-json/wp/v2/users returned a list of author objects with their slug, which is usually the login name. Half of a password-guessing attack is done for the attacker.
• xmlrpc — /xmlrpc.php is enabled. Its system.multicall method packs hundreds of login attempts into one request, which is why brute-force tools prefer it over the login form.
• readme — /readme.html is still present and names the exact WordPress version, narrowing down which published exploits apply.

The scan only reads the responses: an array of user objects, the "XML-RPC server accepts POST requests only" message, and a version number on the readme page. A 401, an empty array or a 404 counts as closed. A leftover wp-config.php.bak is reported under files left behind.

How to fix it

Disable XML-RPC unless Jetpack or the mobile app needs it (security plugins have a switch, or deny xmlrpc.php at the server), restrict the users route to logged-in requests, and delete readme.html after each update. Keep WordPress itself up to date — see CMS detection.