What is WordPress xmlrpc.php (XML-RPC)?

As WPSec.com explains, WordPress “XML-RPC is a remote procedure call (RPC) protocol which uses XML to encode its calls and HTTP as a transport mechanism.”.

Originally, XML-RPC was developed back in the early days of WordPress, where Internet connections were slow and sporadic at best.  In fact, rather than actively writing new posts via the WordPress online user interface, posts were written asynchronously, offline, and then uploaded to the server.  

PHP is the scripting language running on the server machine, hence the .php extension to the filename.

XML stands for extensible markup language.  It’s the encoding mechanism, or data formatting language, that effectively marked up the post that was to be transmitted, into a common structured format that the server could decode, insert into a database, recognize how the post should appear and insert into a blog.

RPC is short for remote procedure call.  It’s simply a way for a call in one location to trigger the execution of a function or routine in another.  Sometimes those locations are common to the same server, but sometimes they’re physically thousands of miles apart.

Note that some RPC’s have been exploited, causing confusion – whereby people think all RPC’s are forms of a virus.  Examples would be the August, 2003 massive Microsoft virus known as MSBlast or W32.Blaster.Worm which ran amok on Windows computers, exploiting a weakness in the DCOM RPC interface.  It spread like wildfire and caused significant chaos.

Because of security concerns, back in 2008 (WordPress 2.6), there was a configurable option that would allow you to enable or disable XML-RPC.  Because of security threats (too many compromised systems), the default option became to disable it.  Then, as mobile clients popularity increased, in WordPress 3.5, the default reverted to being enabled by default.

If you’d like to learn more about XML-RPC and the history of its development, head on over to xmlrpc.com

Why Would I Want XML-RPC Enabled?

The WordPress XML-RPC approach is still used in this modern day and age for making blog posts, whether you’re using a mobile application such as the WordPress mobile app, desktop clients like Windows Live Writer or even unique solutions like If This Then That (IFTTT).  As implausible as it sounds, even WordPress plugins, like JetPack, depend on XML-RPC. The top reasons XML-RPC is enabled by default in WordPress is because of the WordPress iOS client and JetPack.

JetPack uses xmlrpc.php to connect to the WordPress.com website so that it can perform numerous functions.

Besides remote blog posting, there are several things you can accomplish when using XML-RPC within WordPress.  These include post editing, post deletion, adding new image files to a post, pulling back a list of comments and editing comments.

How to Check if XML-RPC is Enabled?

If you’ve got XML-RPC (xmlrpc.php) enabled, it means you’ve got the capability to run JetPack and make blog posts from cell phone clients like iPhones.  But how do you know…. Is XML-RPC enabled on WordPress?

There’s several different ways of checking to see if your XML-RPC is enabled.  Below are two of the easiest, and most common, ways to check if it’s active:

Method #1

1. If you’d like to check if XML-RPC is enabled, just visit the following website: WordPress XML-RPC Validation Service
2. Once there insert your blog URL, for example: xmlrpc
3. If you’ve got XML-RPC enabled, you’ll get a success message, indicating, “Congratulation! Your site passed the first check.”
   • Stop there – do not put in your credentials. At this point you have confirmed that XML-RPC is working, active, enabled and a possible source of compromise.
   • In this case, a success message means XML-RPC is working, visible and potentially a target for hackers!

Method #2

1. Alternatively, you can visit the latter URL of your blog, not the example, directly in your web browser: xmlrpc
2. Check the response.  If you have XML-RPC enabled, you’ll see: XML-RPC server accepts POST requests only.

Why Would I Want to Disable XML-RPC?

In trying to understand why you may want to disable XML-RPC in WordPress, it’s important to understand how it’s used.  We already know that some plugins, and all remote publishing clients, rely on XML-RPC to function. What hasn’t been said is how XML-RPC does its thing.

Each and every time an XML-RPC call is made, it has to be authenticated via a username and password.  Combine that with the system.multicall capabilities, and suddenly every time it’s called, it could be trying out 100 login combos, as a hacker attempting to break in to your blog.  

This amplification of requests, where 1 call can spawn 100 requests is a classic example of how distributed denial of service (DDoS) attacks are made.  If brute force attacks are hitting your site, then eliminating the threat of XML-RPC becomes a clear contender for smart strategies to consider.

The worst part about it is that you can’t block it at the firewall or restrict capabilities.  Otherwise your plugins, and mobile clients, that rely on it – IF ANY – will stop working.

If you don’t absolutely need the plugin or mobile client capabilities, then disabling XML-RPC isn’t a big deal.  It will close the door for some of the most prolific hacking attacks against your WordPress blog.

How to Disable XML-RPC?

In disabling the threats from having XML-RPC enabled, there are several approaches to reducing or eliminating the risk, with each having strengths and weaknesses of their own.  Read on to see exactly how one goes about the steps to disable WordPress XML-RPC (xmlrpc.php).

Option 1 – Deletion

In this scenario, you simply remove the xmlrpc.php file from the server.  It could easily be done via FTP or cPanel. Just login and delete the file using the file browser, or similar, menu..

Advantage:  It’s easily done.  Quick and painless.

Disadvantage:  Once you’ve removed the file, anytime you get a WordPress update or upgrade, you’re going to have to go back in and delete the file all over again.  For that reason, this option is NOT recommended.

Option 2 – Disable via .htaccess

In scenario number 2, instead of removing the file completely, as with Option 1, you’ll instead be keeping the file, but preventing it from being accessed by any processes.  In effect, you’re putting the file in quarantine so it can’t be used against you.

As seen on StackExchange, here’s the approach.  It’s short and sweet:

  # Block WordPress xmlrpc.php requests
  <Files xmlrpc.php>
    order allow,deny
    deny from all
  </Files>

Advantage:  By eliminating the ability to access the file, you’ve eliminated the risky xmlrpc.php file from being operational – a very good thing.

Disadvantages:

• Not every host will allow changes to system configuration files like .htaccess
• If you make changes to .htaccess, forget what this was included for, or otherwise tweak the mechanism that has been disabling XML-RPC from working, it could return to being operational.  Overall, this is a very low probability event, so it’s not a big downside.
• If you get the code wrong, make a typo or other error, you could break your site

Option 3a – Disable via Functions.php in WordPress Theme Files

In scenario number 3a, instead of removing the file completely, or disabling it by editing a key server configuration file, with this method, you’re relying on a theme file from within WordPress.  It’s great for hosts with restrictive access or so that you can keep all your functionality within the WordPress directory tree.

This approach creates two filters (action hooks) and one function.

Add a filter to identify XMLRPC as not enabled:

  add_filter( 'xmlrpc_enabled', '__return_false' );

Add a filter to disable X-Pingback in the WordPress headers:

  add_filter( 'wp_headers', 'disable_x_pingback' );

Set up the function to do the disabling:

  function disable_x_pingback( $headers ) {

Unset the headers:

    unset( $headers['X-Pingback'] );

Return the modified headers:

    return $headers;

End the function:

  }

Full Version of the disable XMLRPC code:

  add_filter( 'xmlrpc_enabled', '__return_false' );
  add_filter( 'wp_headers', 'disable_x_pingback' );
  function disable_x_pingback( $headers ) {
    unset( $headers['X-Pingback'] );
    return $headers;
  }

Usage notes:

If you’re using the default theme, edit the functions.php file and then get the theme updated, your changes will be overwritten and gone.

If you’re using the default theme, then change to a different theme, your changes will no longer be present.

Best practices call for themes to be regularly used and updated, so you should put your changes into a child theme so that they are preserved, even when the main theme gets updated.

If you make an error in rekeying the above, omit a bit of punctuation during a copy and paste, or generally make any kind of fat fingering error at all, you can bet that there will be some type of error or crash generated as a result.

This will only disable the authenticated multicall functions X-Pingback.  If you need to disable the single post/page as well, then also add the below.

  add_filter('pings_open', '__return_false', PHP_INT_MAX);

Option 3b – Disable via Functions.php in WordPress Theme Files

Reviewing the WordPress documentation on this, if you want to disable XML-RPC functionality, via WordPress functions, you’ll find the xmlrpc_methods approach.  With this, you’re effectively gutting the entire ability of WordPress to use XML-RPC, completely eliminating the endpoints!

So, in scenario number 3b, a very streamlined approach can be undertaken:

Set a blanket function to cover the xmlrpc_methods:

  add_filter('xmlrpc_methods', function () {

Return nothing when it’s called:

  return [];

End the function:

  }, PHP_INT_MAX);

Full Version of the disable XMLRPC code:

  add_filter('xmlrpc_methods', function () {
    return [];
  }, PHP_INT_MAX);

Usage notes:

These are the same as most of 3a above, or any other theme-based functions.php edits.

The key difference with this approach is that you’re gutting anything where WordPress would make XML-RPC calls.  So, you’ll know that none of them are going to work and can rest easy about anyone using xmlrpc.php against you.

Just don’t forget to put these changes in a child theme so that you don’t lose your custom coding whenever the main theme gets updated!

Option 4 – Disable via a WordPress Plugin

The plugin approach is always a popular one, including when you’re wanting to disable XML-RPC within WordPress.  The thing about plugins are, sometimes they get updated, but sometimes they don’t. If they don’t get updated, they can become the security risk, rather than the thing they’re trying to fix!  

While you can find a number of plugins out there which will disable xmlrpc.php from doing what it does, there are some which only disable some functions, or there are bigger, heavier plugins which have many other security functions at the same time.  We’ve got a huge section on WordPress security, so check it out. 

Here’s two popular plugins for disabling XML-RPC.  The first is a full slash and burn, while the second is only a partial disabling of functions.  Note that you’ll be disabling pingbacks, some plugins and the ability to remote post.

Plugin to fully disable xml-rpc Disable XML-RPC

Plugin to partially disable xml-rpc functions used by hackers Stop XML-RPC Attacks

Option 5 – Use Cloudflare WAF to Allow JetPack but Otherwise Block

If you’re running Cloudflare, then take advantage of the Cloudflare WAF to protect your WordPress blog from being hit, while still allowing JetPack to run.

Here’s the full explanation of how it works: WordPress Jetpack and Cloudflare

Overall, this is an outstanding approach that can let you have your cake and eat it too!

Learn about the Cloudflare Web Application Firewall (WAF) and how it can work with, or without JetPack, visit the Cloudflare website: cloudflare.com

Conclusions about Disabling XML-RPC

Choose any method that works for you.  If you’ve got Cloudflare WAF, then consider Option 5.  Otherwise, Option 3b above is probably the most elegant, effective and easily administered.  

If you’re having trouble deciding, reread your options and weigh the pro’s and con’s.  If all else fails, consider 5 or 3b. Good luck!