Disable XML-RPC In WordPress

What this check and mySites.guru tool looks at on your site

This check requests xmlrpc.php on your site and checks whether it’s still reachable and responding to XML-RPC calls. A site that has blocked or disabled the endpoint, whether at server level or through a plugin filter, passes. A site where the file responds normally fails, whether or not you’re aware the feature exists on your install.

The two ways xmlrpc.php gets abused

XML-RPC is a protocol for remote procedure calls, and xmlrpc.php is the single file WordPress uses to implement it. Every request to that one endpoint can trigger any of dozens of WordPress methods: creating a post, uploading media, editing a comment, or authenticating a user, all specified inside the request body rather than through separate URLs. That design is exactly what made it useful for early desktop blogging software, and it’s still what the Jetpack plugin and WordPress’s official mobile apps lean on today.

The same design is also what makes it a persistent target. Two problems come up repeatedly:

Brute-force amplification. XML-RPC supports a method called system.multicall, which bundles many separate method calls into a single HTTP request. An attacker can pack hundreds of username and password combinations into one request instead of sending hundreds of individual login attempts. Most simple rate-limiting counts requests, not the login attempts hidden inside them, so this sails straight past defences that would otherwise catch a conventional brute-force attack against wp-login.php.

Pingback abuse. The pingback.ping method lets one site notify another that it’s been linked to. Attackers have used it to make WordPress sites unknowingly participate in denial-of-service attacks against a third party: they ask thousands of vulnerable sites to “pingback” a single target URL simultaneously, and each site’s server dutifully makes an outbound request on the attacker’s behalf. Your site becomes part of someone else’s attack, using your server’s resources and, potentially, your IP reputation.

Neither of these is a theoretical risk. Both are attack patterns that show up in server logs on a scanned-and-forgotten XML-RPC endpoint within days of it being left exposed. If you’ve never looked, checking your access logs for repeated POST /xmlrpc.php requests, particularly clustered bursts from the same handful of IP addresses, is usually enough to confirm the endpoint is already being probed on your site, whether or not anything has succeeded yet.

Automated scanners look for xmlrpc.php on essentially every WordPress install they find, not just ones that have shown any other sign of weakness, because the file’s presence alone is the trigger. It doesn’t matter how obscure your site is or how little traffic it gets. If it’s running WordPress with the endpoint reachable, it’s on the list.

Blocked entirely, or trimmed to what you use

If you don’t use Jetpack and don’t rely on remote publishing through the mobile apps, the endpoint should be blocked entirely. If you do use either, the more targeted fix is disabling the specific methods responsible for the abuse, pingback.ping and system.multicall, while leaving the rest of XML-RPC working for the features that need it.

How to fix it

Option A: block it completely, if nothing on the site uses XML-RPC. Add this to your .htaccess file in the site root:

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

On nginx, inside your server block:

location = /xmlrpc.php {
    deny all;
}

Option B: disable it through WordPress itself, which is easier to reverse and doesn’t require server access. Add this to your theme’s functions.php or a small site-specific plugin:

add_filter( 'xmlrpc_enabled', '__return_false' );

Option C: keep XML-RPC, but remove only the risky methods, if you rely on Jetpack or the mobile apps and want to keep them working:

add_filter( 'xmlrpc_methods', function ( $methods ) {
    unset( $methods['pingback.ping'] );
    unset( $methods['system.multicall'] );
    return $methods;
} );

1. Check whether you actually use Jetpack or remote publishing through a mobile app before choosing an option. If you don’t, Option A or B is the simpler, more complete fix.
2. Apply the relevant snippet.
3. Confirm the change: request https://yoursite.com/xmlrpc.php directly. A blocked endpoint returns a 403; a disabled-but-reachable one returns an XML-RPC fault message rather than the normal server description.
4. If you use Jetpack, check it still connects correctly after the change, particularly if you chose Option A or B rather than C.
5. If you went with Option C and kept XML-RPC partially available, check your access logs again a week or two later to confirm the volume of POST /xmlrpc.php traffic has actually dropped. Scanners that were finding login and pingback methods available will usually move on once those specific calls start failing.

What mySites.guru does about it

mySites.guru checks every connected WordPress site for a reachable XML-RPC endpoint on each snapshot, twice a day, and can disable it with one click across every connected site at once, rather than editing each one by hand.