How to Disable XML-RPC in WordPress (and When Not To)

What XML-RPC is

XML-RPC is a way for outside programs to talk to WordPress by sending XML to xmlrpc.php in your site's root. Before WordPress had a REST API, it was how mobile apps, desktop publishing tools and other sites controlled a WordPress site.

It has been enabled by default since WordPress 3.5. Today the REST API does most of what XML-RPC once did, so many sites carry it without using it.

Why it is a risk

Every way in must be defended, and XML-RPC offers three useful tricks to attackers.

• Many guesses in one request. The system.multicall method lets a bot try many username and password pairs in one request, which can slip past tools that count failed login page requests.
• Pingback abuse. The pingback feature has been used to make sites send requests to other sites, which helps attackers hide and amplify attacks.
• It skips your login page. Hiding or protecting wp-login.php does nothing for requests sent to xmlrpc.php.

Check whether XML-RPC is on

Open https://yoursite.com/xmlrpc.php in a browser. A message saying that the XML-RPC server accepts POST requests only means it is switched on. A 403 or 404 means it is blocked or missing.

For a proper test, send a request that lists the methods. A list of method names in the response confirms it is open.

curl -s -X POST https://yoursite.com/xmlrpc.php \
  -H "Content-Type: text/xml" \
  -d '<?xml version="1.0"?><methodCall><methodName>system.listMethods</methodName></methodCall>'

Who still needs it before you disable XML-RPC in WordPress

Before you disable XML-RPC in WordPress, check that nothing you rely on uses it.

• Jetpack, whose connection to WordPress.com has historically used XML-RPC. Check the plugin's current documentation.
• Older mobile apps and desktop publishing tools. Recent official apps mostly use the REST API instead.
• Some remote publishing, migration and site management services that connect to your site.
• Any custom script you wrote years ago that posts content by XML-RPC.

Method 1: Block it at the server

The cleanest way is to stop requests before WordPress loads. That saves server work during an attack and does not depend on any plugin.

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

Method 2: Block it in nginx

On nginx, add a location rule to the server block and reload the configuration.

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

Method 3: Use a WordPress filter

If you cannot change the server, a filter turns off the XML-RPC methods that need a login. This is the weakest option, because the file still answers requests and loads WordPress. Treat it as a stopgap, and prefer a server rule or a plugin that refuses the request outright.

Remember also to turn off pingbacks if you are not using them.

add_filter( 'xmlrpc_enabled', '__return_false' );

After you disable it

Check that nothing broke, then check the block works.

1. 1Run the curl test again. You should get a 403, 404 or an error instead of a method list.
2. 2Check that Jetpack, your publishing tools and any integrations still work.
3. 3Look at your logs a few days later. Requests to xmlrpc.php should be refused quickly.
4. 4Also consider turning off application passwords if nothing uses them, since they are another way to authenticate without the login form.