The XML-RPC WordPress specification was developed to standardize communication between different systems, meaning that applications outside WordPress (such as other blogging platforms and desktop clients) could interact with WordPress.
This specification has been a part of WordPress since its inception and did a very useful job. Without it, WordPress would have been in its own silo, separated from the rest of the internet.
However, xmlrpc.php has its downsides. It can introduce vulnerabilities to your WordPress site and has now been superseded by the WordPress REST API, which does a much better job of opening up WordPress to other applications.
In this post, we’ll explain what xmlrpc.php is, why you should disable it, and help you identify whether it’s running on your WordPress site.
Ready? Let’s dive in!
What Is xmlrpc.php?
XML-RPC is a specification that enables communication between WordPress and other systems. It did this by standardizing those communications, using HTTP as the transport mechanism and XML as the encoding mechanism.
XML-RPC predates WordPress: it was present in the b2 blogging software, which was forked to create WordPress back in 2003. The code behind the system is stored in a file called xmlrpc.php, in the root directory of the site. And it’s still there, even though XML-RPC is largely outdated.
In early versions of WordPress, XML-RPC was turned off by default. But since version 3.5, it’s been enabled by default. The main reason for this was to allow the WordPress mobile app to talk to your WordPress installation.
If you used the WordPress mobile app before version 3.5, you may recall having to enable XML-RPC on your site for the app to be able to post content. This was because the app wasn’t running WordPress itself; instead, it was a separate app communicating with your WordPress site using xmlrpc.php.
But it wasn’t just the mobile app that XML-RPC was used for: it was also used to allow communication between WordPress and other blogging platforms, it enabled trackbacks and pingbacks, and it powered the Jetpack plugin which links a self-hosted WordPress site to WordPress.com.
But since the REST API was integrated into WordPress core, the xmlrpc.php file is no longer used for this communication. Instead, the REST API is used to communicate with the WordPress mobile app, with desktop clients, with other blogging platforms, with WordPress.com (for the Jetpack plugin) and with other systems and services. The range of systems the REST API can interact with is much greater than the one allowed by xmlrpc.php. Also, there is much more flexibility.
Because the REST API has superseded XML-RPC, you should now disable xmlrpc.php on your site. Let’s see why.
Why You Should Disable xmlrpc.php
The main reason why you should disable xmlrpc.php on your WordPress site is because it introduces security vulnerabilities and can be the target of attacks.
Now that XML-RPC is no longer needed to communicate outside WordPress, there’s no reason to keep it active. That’s why it’s wise to make your site more secure by disabling it.
If xmlrpc.php is a security liability and it no longer does a job, why hasn’t it been removed from WordPress altogether?
The reason for this is because one of the key features of WordPress will always be backward compatibility. If you’re managing your site well, you will know that keeping WordPress up-to-date, as well as any plugins or themes, is essential.
But there will always be website owners who are unwilling or unable to update their version of WordPress. If they are running a version that predates the REST API, they will still need access to xmlrpc.php.
Let’s look at the specific vulnerabilities in more detail.
DDoS Attacks via XML-RPC Pingbacks
One of the functions that xmlrpc.php enabled was pingbacks and trackbacks. These are the notifications that appear in the comments on your site when another blog or site links to your content.
The XML-RPC specification was what made this communication possible, but that’s been replaced by the REST API (as we saw already).
If XML-RPC is enabled on your site, a hacker could potentially mount a DDoS attack on your site by exploiting xmlrpc.php to send vast numbers of pingbacks to your site in a short time. This could overload your server and put your site out of action.
Brute Force Attacks via XML-RPC
Each time xmlrpc.php makes a request, it sends the username and password for authentication. This presents a significant security liability and is something that the REST API does not do. In fact, the REST API uses OAuth which sends tokens for authentication instead of usernames or passwords.
Because xmlrpc.php sends authentication information with every request, hackers could use it to try to access your site. A brute force attack like this might allow them to insert content, delete code, or damage your database.
If an attacker sends enough requests to your site, each with a different username and password pair, there is a chance they could eventually hit on the right one, giving them access to your site.
That’s why, if you are running an up-to-date version of WordPress, which uses the REST API to communicate with external systems, you should disable xmlrpc.php. It isn’t needed and it could be making your site vulnerable.
Is xmlrpc.php Running on Your WordPress Site?
The first thing you need to do is identify whether xmlrpc.php is running on your WordPress site.
This isn’t a simple case of checking whether the file is there: it’s part of every WordPress installation and will be present even if XML-RPC is disabled.
To check if xmlrpc.php is enabled on your site, use the WordPress XML-RPC Validation Service.
If you run the check and discover that xmlrpc.php is still enabled on your site, how do you turn it off?
How to Disable xmlrpc.php
There are three ways to disable xmlrpc.php:
Let’s take a look at each one individually.
How to Disable xmlrpc.php with a Plugin
Installing a plugin to disable xmlrpc.php is the easiest way to do this. The Disable XML-RPC plugin will disable it completely. Here’s how you use it.
My starting point is my own website, on which xmlrpc.php is enabled. You can see this via the check I did:
Install the plugin via your Plugins screen in the WordPress admin, and activate it.
You don’t have to do anything else: activating the plugin will cause it to disable XML-RPC. Now if I run a check on my site, I get a different result:
It’s that simple!
Disable XML-RPC Pingbacks with a Plugin
But what if you want to disable some aspects of xmlrpc.php and not others? The Disable XML-RPC Pingback plugin lets you disable just the pingback functionality, meaning you still have access to other features of XML-RPC if you need them.
The plugin works in the same way as the Disable XML-RPC plugin: just install, activate it, and it will work.
Configure XML-RPC and REST API Activation with a Plugin
If you want more fine-grained control of how both xmlrpc.php and the REST API are configured on your site, you can install the REST XML-RPC Data Checker plugin.
Once you’ve installed and activated this plugin, go to Settings > REST XML-RPC Data Checker and click the XML-RPC tab.
This lets you configure exactly which aspects of xmlrpc.php are active on your site.
Alternatively, you can simply switch it off altogether. And if you also want control over the REST API, the plugin gives you another tab for that.
How to Disable xmlrpc.php Without a Plugin
If you’d rather not install another plugin on your site, you can disable xmlrpc.php by adding some code in a filter, or to your .htaccess file. Let’s look at both methods.
Disable xmlrpc.php via a Filter
An option here is to use the xmlrpc_enabled filter to disable xmlrpc.php. Add this function to a plugin and activate it on your site:
add_filter( 'xmlrpc_enabled', '__return_false' );You could add this to your theme functions file but it’s better practice to write a plugin.
The other option has to do with editing your .htaccess file, which is available with hosting providers that use Apache, by connecting to your site’s server via FTP or cPanel.
Disable xmlrpc.php via the .htacess File
In your .htaccess file, add this code:
<Files "xmlrpc.php">
Require all denied
</Files>Make sure you make a copy of the old file before you do so, just in case you run into any issues.
Have Your Hosting Provider Disable xmlrpc.php
Alternatively, some hosting providers will disable xmlrpc.php if an attack is detected.
This will produce a 403 error and stop the attack in its tracks.
At Kinsta, there is no need to worry, this is already blocked. Contact support regarding any issues
If you’re doing this yourself, it’s best to use one of the methods above. But before you do, always check with your hosting provider first.
When Do You Need to Enable xmlrpc.php?
There might be some occasions in which you do need to enable xmlrpc.php on your WordPress site or when you shouldn’t completely disable it.
These are:
- You’re not running the REST API (not advised, but necessary in some situations) but need to communicate between your WordPress site and other systems.
- You’re unable to update WordPress to version 4.4 or higher, so don’t have access to the REST API. This might be because of restrictions in your hosting setup (in which case I would change hosting provider) or incompatibility of theme or plugins (in which case I would replace or update those).
- You’re working with an external application that can’t access the WP REST API but can access XML-RPC (in the long term, I’d advise updating that application or switching to a REST-compatible application).
That’s it! None of these are particularly good reasons for keeping the XML-RPC specification switched on.
The only reason it’s still in WordPress is for backward compatibility and you’d use it only if you’re working with outdated systems. For anyone wanting to keep their sites up to date and working with the latest technology, disabling xmlrpc.php is the way to go.
Summary
The XML-RPC specification was developed before WordPress was even created, as a means for WordPress to communicate with external systems and applications. It has inherent security flaws and could make your site vulnerable to attack.
Now that the REST API lets your site communicate with other applications, you can safely disable xmlrpc.php. If you follow the steps above, by disabling it you’ll improve your site’s security.
Rachel McCollin has been helping people build websites with WordPress since 2010. She's a huge fan of self-hosted WordPress and wants to help as many people as possible create an awesome website with it.
Only reason to leave XLM-RPC enabled at this point is for Zapier integration. As soon as they switch to REST API, I’ll be disabling XML once and for all.
But Jetpack’s official website states something different:
“Check xmlrpc.php, Jetpack needs this file to connect to WordPress.com”.
Did I misunderstand something?
@Ryan: IFTTT also uses XLM-RPC.
Hello Nauman, the last section of the post (When Do You Need to Enable xmlrpc.php?) details some situations where you may still need xmlrpc.php – Jetpack and IFTTT would be two examples. For people who don’t use any of these services, it’s best to disable it.
Thanks Brian for the clarification.
Loving the article. I am currently dealing with a Brute Force form some SOB in Croatia. They didn’t start using a poxy until i limited the login attempts do i have their starting location. I found your article on moving the login page but even after that they found it. I I checked the logs and saw they came in via the XLM, just disabled that with the help of this article and we’ll see if that slows them down.
About the code snippet in the config file – Why add an Nginx location directive in wp-config.php?