WordPress xmlrpc.php enabled

Scan.now sends a single GET /xmlrpc.php. An enabled endpoint answers with HTTP 405 and the body "XML-RPC server accepts POST requests only."; a 403 or 404 means it has been disabled or blocked, and the check passes. Scan.now also looks for an X-Pingback response header on the homepage, which WordPress adds to advertise the endpoint. No POST request, no method call and no authentication attempt is made. Rated medium: the endpoint is not a vulnerability on its own, but it is a second authentication surface with weaker protections than wp-login.php, and it is the usual vehicle for the brute-force and amplification abuse described below. It is checked only when WordPress is detected; see also wordpress-user-enumeration, which supplies the usernames that make brute force practical.

XML-RPC predates the REST API and was how mobile apps and desktop clients published to WordPress. Three properties make it a liability today. First, the system.multicall method lets one HTTP request carry hundreds of wp.getUsersBlogs calls, each with a different password, so an attacker can test thousands of credentials per minute while login-rate-limiting plugins that only watch wp-login.php see nothing. Second, most two-factor plugins hook the normal login form and not XML-RPC, so a 2FA-protected account can still be brute-forced here. Third, the pingback.ping method makes your server fetch an arbitrary URL, which has been used to turn fleets of WordPress sites into a distributed denial-of-service amplifier against third parties, and to probe internal networks. Jetpack and a few remote-publishing clients still use the endpoint; most sites do not need it. The WordPress scanning guide ranks this among the first things to close.

If nothing you use depends on it, block the file at the web server, which is more complete than the WordPress filter. nginx:

location = /xmlrpc.php {
    deny all;
    return 403;
}

Apache (vhost or .htaccess):

<Files "xmlrpc.php">
    Require all denied
</Files>

Cloudflare WAF custom rule: expression (http.request.uri.path eq "/xmlrpc.php"), action Block; add an exception for Jetpack's published IP ranges if you rely on it. If you must keep the endpoint for one client, disable the dangerous methods and remove the advertisement instead:

add_filter('xmlrpc_enabled', '__return_false');        // disables authenticated methods
add_filter('xmlrpc_methods', function ($methods) {
    unset($methods['pingback.ping'], $methods['system.multicall']);
    return $methods;
});
add_filter('wp_headers', function ($headers) { unset($headers['X-Pingback']); return $headers; });

Note that xmlrpc_enabled only turns off methods that require authentication; the file still responds, which is why the server-level block is preferred. Whichever route you take, also enforce strong passwords and a login limiter, because wp-login.php remains.