Updates on CyberSecurity, WordPress and what we're cooking in the lab today.

Should You Disable XML-RPC on WordPress?

This entry was posted in WordPress Security on October 12, 2015 by Mark Maunder   54 Replies

A few questions came up in our recent blog post, where we discuss XML-RPC brute force attacks, about disabling XML-RPC on WordPress. To allay any confusion, we thought we would describe exactly what XML-RPC does and whether you should consider disabling it.

XML-RPC on WordPress is actually an API or “application program interface“. It gives developers who make mobile apps, desktop apps and other services the ability to talk to your WordPress site. The XML-RPC API that WordPress provides gives developers a way to write applications (for you) that can do many of the things that you can do when logged into WordPress via the web interface. These include:

  • Publish a post
  • Edit a post
  • Delete a post.
  • Upload a new file (e.g. an image for a post)
  • Get a list of comments
  • Edit comments

For a full list of the WordPress API functions available to developers via XML-RPC, take a look at this page on the WordPress codex.

If you disable the XML-RPC service on WordPress, you lose the ability for any application to use this API to talk to WordPress.

Lets use an example to illustrate: You have an app on your iPhone that lets you moderate WordPress comments. Someone advises you to disable XML-RPC. Your iPhone app suddenly stops working because it can no longer communicate with your website using the API you just disabled.

To us, disabling XML-RPC comes with a cost. You are disabling a major API in WordPress. We briefly provided this capability, but removed the feature because WordPress’s own API abuse prevention has improved. Furthermore, providing the ability to disable XML-RPC caused confusion among users when their applications broke because they could not access the API.

Jetpack is one of the most popular plugins for WordPress and relies heavily on XML-RPC to provide its features. It is developed by Automattic, makers of WordPress. If you visit the “Known Issues” page for Jetpack, you’ll notice they discuss how certain security plugins can impact Jetpack features if you use them to disable XML-RPC.

The following two kinds of attacks on XML-RPC have received press coverage during the past 2 years.

  • DDoS via XML-RPC pingbacks. This is actually not a very effective form of DDoS and anti-spam plugins like Akismet have gotten good at spotting this kind of abuse.
  • Brute force attacks via XML-RPC. These are completely ineffective if you’re using Wordfence because we simply block the attacker after they reach the login attempt limit.

If you still want to disable XML-RPC, there are several plugins to choose from in the official WordPress repository. You will lose any XML-RPC API functionality that your applications rely on. We don’t disable XML-RPC on our own sites.

We hope this has been helpful and cleared up some confusion we’ve seen in our comment threads. As always we very much welcome your comments below.

 

 

Did you enjoy this post? Share it!


4.00 (12 votes) Your rating:

54 Comments on "Should You Disable XML-RPC on WordPress?"

Chris October 12, 2015 at 10:31 am • Reply

Hi Mark, according to some blogs you also must block access to xmlrpc.php on the Apache or Nginx server like from htaccess or etc... because the plugins that disable XML-RPC do not fully disable access to that file... is this true or not? Example claim here:

https://www.littlebizzy.com/blog/disable-xml-rpc

I can't find the other link but I think Syed Balkhi made a similar claim last year. Thanks.

Beth Terry October 12, 2015 at 10:38 am • Reply

I recently started up a new blog in addition to my other blog and website, all written in WordPress. My web guru highly recommended WordFence as the first plugin to download. I am DELIGHTED with the results and want to publicly thank you for this service. I signed up for the premium version right away.

In the past month this has turned out to be one of the smartest moves I could make. All three of my sites showed *hundreds* of attempted log-ins by hackers from what appeared to be 40 different countries. You guys throttled those suckers and so far my site is safe. I appreciate the work you did to create this plugin, and I appreciate having your blog for further research.

I have recommended WordFence to all my fellow speakers and consultants. It's a great product! Thank you Thank you!
Beth Terry, CSP

Ron McLean October 12, 2015 at 12:10 pm • Reply

I agree Beth, I have the paid version of Wordfence on two of my sites, it's amazing how many attacks there are, you would think we have gold buried in our blogs?

Darren October 12, 2015 at 12:18 pm • Reply

I expect you're seeing "admin" as the number one attempted username? In addition to adding Wordfence to your site, you might want to go into phpMyAdmin and change the user_nicename row, which I believe is under the wp_options table.

Changing user_nicename hides your username from your WordPress author archives slug.

PseudoGeek October 12, 2015 at 6:22 pm • Reply

Excellent point! Another way to accomplish this: In the WP dashboard, just go to Users and set up a nickname that is different than your login name. Below that, in the dropdown box, select to display your nickname. Whichever way you do it, I heartily agree with your point.

Brian Lee October 13, 2015 at 8:28 am • Reply

user_nicename is in the wp_users table. Changing that column was the only way I could get Wordpress to stop showing my login ID in the URL for each blog post.

Darren January 4, 2016 at 4:41 am • Reply

Out of the box, WordPress is not all that secure. It's amazing how many times you'll see "admin" in an author archive slug.

P. Jacobo October 12, 2015 at 10:46 am • Reply

Most helpful! Thank you for explaining the XML-RCP more thoroughly.

Craig Keefner October 12, 2015 at 10:50 am • Reply

Thanks for the info. A few years back I was getting tormented by pingbacks and have been using plugin "Disable XML-RPC Pingback" plugin to kill them. I've disabled it now and will run with Wordfence (Premium) and see how that goes.

Grant R. October 12, 2015 at 10:51 am • Reply

Thanks for the very well-written and helpful explanation. Keep up the great work!

Mitchell October 12, 2015 at 11:01 am • Reply

I block xmlrpc when I create a WP site.

Why would I need an app to approve a comment or edit a post on my phone, when I can use WP?

I can update multiple sites on phone with InfiniteWP.

If I wanted more remote features,
I would use WP API.

Best wishes,
Mitchell

Mike M. October 12, 2015 at 11:02 am • Reply

Another way is to decline access to the xmlrpc.php file via the htaccess. If needed, you can allow certain IP/subnet access.

Order Deny,Allow
#If needed to allow IP's.
#Allow from 192.168.1.1
#If needed to allow IP subnet's.
#Allow from 192.168.0.0/24
Deny from all

Denver Prophit Jr. February 14, 2017 at 11:02 am • Reply

That's exactly right! You can whitelist and blacklist. Easier to whitelist a few and blacklist the rest.

Colin Powers October 12, 2015 at 11:08 am • Reply

Thanks for the elaboration. I'm not sure how it happened, but both my sites were penetrated about 10 days ago and malicious scripts were placed in my "functions.php" files. I had Wordfence buttoned down very tight (after some earlier attacks), but the hackers still penetrated my login system. Fortunately, Wordfence both alerted me to the incursions and identified the corrupted files. I was able to clean up the scripts and add two factor authentication before the sites could be re-penetrated.
Interestingly, cleaning things up was similar to poking a hornets nest... Wordfence began reporting hundreds of foiled admin login attempts in the following 72 hours...

mark October 12, 2015 at 11:19 am • Reply

Hi Colin,

Sorry to hear you were hacked - glad to hear Wordfence caught the intrusion. I'd encourage you to work with our support team either on our free forums at https://wordpress.org/support/plugin/wordfence or in our premium ticketing system at https://support.wordfence.com/ to get this resolved. It's not really related to the blog entry above, but our team will be more than happy to work with you and may be able to provide more data. It's important to note that there are a huge number of vectors (points of entry) a hacker can use to infect a WP site including other shared hosting accounts, other applications, other WP installations on the same account and so on.

Regards,

Mark.

118Group October 12, 2015 at 11:20 am • Reply

This is a great post, thanks for keeping us in the know.

David October 12, 2015 at 11:32 am • Reply

A lot of my clients use WP and I always recommend Wordfence.

Sometimes though I wonder about WP and people riding on issues and fixing and recommending software when they should not really happen in the first place if the code was well written.

williamp October 12, 2015 at 12:04 pm • Reply

It still seems like a security weakness. I disabled XML-RPC as I have no reason to use mobile apps to update my site, and doing so stopped the latest round of attempted intrusions at my website (and there were hundreds of attempted intrusions over the weekend). So at least in my case having the option of disabling it worked well.

Marcelo October 12, 2015 at 12:17 pm • Reply

Anyway, if you don't use JetPack or apps relying on XML RPC, you can deactivate it safely, and your website will be less prone to this kind of attacks.

Even more, I deactivate this feature in all my sites, even those using JetPack, and it only get screwed when activating/deactivating JetPack modules.

Matt O'Gara October 12, 2015 at 12:25 pm • Reply

Thanks for all the info and clearing up what XML-RCP actually does. Great product and
one I have installed on all my blogs.

Thanks again.

Geek naji October 12, 2015 at 12:36 pm • Reply

Thanks for the Updates

Marcel Preda October 12, 2015 at 1:43 pm • Reply

Thanks a lot for clarification. I was always in doubt about what RPC does in case of Wordpress.
My site was hacked few weeks ago, I've miss to upgrade Wordpress at that moment. After clean install I've installed also Wordfence plugin. I have to admit that it works better than I've expected; I'm a programmer, and I don't trust always what the owners of the tools/apps/plugin claim.
It's a real pleasure to look at the attack tentative in the log.

Yeremyah October 12, 2015 at 2:14 pm • Reply

When I run WordFence only, I get many attacks. Yet since I disabled XML-RCP using the Plugin by Philip Erb, the attacks have stopped. I also use Jetpack but have not seen any issues, and everything still works fine. I recommend disable XML-RCP all together and see if your website and tasks that you normally do still function OK, if yes, keep XML-RCP disabled as it definitely makes a difference to stopping attacks.

mark October 12, 2015 at 2:17 pm • Reply

Just want to point out that, yes you're seeing attacks, but those attacks are being blocked, which is why you're seeing them.

PrinterGirl October 12, 2015 at 4:04 pm • Reply

Just to clarify...do you need the PREMIUM version of WordFence to thwart these attacks?

mark October 12, 2015 at 4:34 pm • Reply

The free version of Wordfence includes all the protections against XML-RPC based brute force attacks that we have discussed.

Regards,

Mark.

Nigel Freeney October 12, 2015 at 5:20 pm • Reply

Hi Mark,

I'm glad that my post prompted this response. I'm not an expert with WordPress and PHP I'm more familiar with Microsoft solutions and use WordPress because a lot can be achieved with minimal technical skill. This background knowledge is useful so I can understand some of the downsides to renaming the xmlrpc.php file to block it from brute force attacks. I still think there needs to be a more elegant security solution developed on a needs must because clearly the weakness of the remote login file access has been identified and is being exploited with DDOS attacks which disable the site through tying up the server's resources. Two of my sites that have been running for years have been hit within 7 days of each other using this method. Leaving the file unblocked was simply not an option.

emmanuel October 12, 2015 at 11:00 pm • Reply

dont disable xml-rpc...buh put a security dat will make it more secured..and only readable by jetpack

Mark October 12, 2015 at 11:07 pm • Reply

We often use WordFence for our clients and once you know how to use it it is perfect. This post clears up many questions we are getting about the Brute Force XML-RPC problems currently being experienced. As Mark says WordFence has blocked these attacks so far, but this is dependant on how you have setup WordFence. Mark you might like to point out how to set this up.
W all the interest in WordPress Security at the moment, those that are not familiar with it can see our Simple WordPress Security Checklist https://wpwss.com/wordpress-security-checklist-best-practices/. It is basic but gives a good foundation to start with.

Keith Taylor October 13, 2015 at 11:24 pm • Reply

That's not fair!

You're suggesting wpengine in your article, yet Wordfence is on their banned plugins list! I suspect they ban it because it identifies the IP addresses of spammers and hackers. You can then use CloudFlare to completely lock out those addresses, typically saving one third of your bandwidth. wpengine's would charge you for those hits, so they lose the revenue.

Anyway, a site protected by CloudFlare and Wordfence is far faster than anything wpengine can manage.

Andronicus October 12, 2015 at 11:52 pm • Reply

Wordfence has kept my blog completely free of problems so far. As well, I regularly check the 'live traffic' and "Wordpress statistics info, and immediately permanently block the specific IP of anyone who attempts to access xmlrpc even if its only been once.

I'm more than happy with Wordfence and have gone premium, because I really appreciate the effort the developers have put into the product.

Just as a matter of general interest, one day my blog had 10,000 xlm-rpcs in a few hours, and just recently over 8300 - all of which were successfully blocked.

Phil Horsepool October 13, 2015 at 12:53 am • Reply

Recently I have noticed very many more attempted logins, which Wordfence stops every time.
The most recent on one of my client sites was an attempt every 4 seconds over a period of 3 hours. The worrying thing was that every single IP was different and the reported locations came from 20 or so different countries so obviously a well co-ordinated hack system somewhere.
Due to Wordfences numerous options I have sites set up so that the usual culprits such as admin and administrator automatically get banned, and only 2 attempts are ever allowed regardless of the user name.
I also go in on a regular basis and permanently block IP's that have had a failed attempt which seems to reduce the number of attempts over time.
One thing that I have found to help the more crude attempts is having a captcha system on the login page as most of the automated attempts can't seem to bypass this. Possibly something for Wordfence to incorporate in a future update?

Srinivasm October 13, 2015 at 1:17 am • Reply

thanks wordfence team, for including all the necessity security protection in free version plugin also.

flyer October 13, 2015 at 4:40 am • Reply

finally I don,t know, should I block it or not ?

Andries October 13, 2015 at 7:25 am • Reply

WordFence does block brute force attacks through wp-login.php and xmlrpc.php, but for every attempt, at a minimum, the WordPress core and WordFence must be loaded to block these attempts. These attacks use resources that are often limited on shared hosting.

If you don't use it, disable XMLPC in your htaccess.

# START XML RPC BLOCKING

Order deny,allow
Deny from all

# FINISH XML RPC BLOCKING

Michael October 13, 2015 at 11:36 am • Reply

I was wondering, why doesn't Wordfence blacklist the IP_address that is performing the BruteForce attack. I get lots of attempts to penetrate port 22 but I ban them after 3 attempts. I also ban them from my email server and web server. It seems Wordfence should do the same with the WP site that someone is attempting to hack or is that an option?

Thank everyone for all your helpful posts.

Regards,

The Rooster

Ahsan Parwez October 18, 2015 at 11:41 pm • Reply

Great post and explanation. We at Cloudways are fans and admirers of Wordfence and now recommending it to all our WordPress clients.

Steve October 27, 2015 at 1:54 pm • Reply

Thanks as always for your great work Wordfence crew.

We're noticing a mass of hit to xmlrpc.php (plus index.php and wp-login.php) across multiple sites and despite WordFence doing its job and blocking them, the logs showing 503, they're still attempting over and over and over again and really consuming server resources.

Any suggestions?

Cheers, Steve

mark October 27, 2015 at 1:57 pm • Reply

Hi Steve,

Not sure if you've tried Falcon, but if you enable it, your IP blocking is moved into your .htaccess, along with enabling caching. This will give you a huge performance increase.

Regards,

Mark.

Steve October 27, 2015 at 2:05 pm • Reply

Wow, quick response there Mark, thanks :)

We have used Falcon on some sites and it's been good. Unfortunately we also have a few that use some ajax functionality that we've yet to find a caching solution for.

mark October 27, 2015 at 2:10 pm • Reply

I wonder if breaking out the feature that puts IP blocking into your .htaccess file might be a good idea. i.e. you can get that without having to enable caching.

Steve October 27, 2015 at 4:16 pm • Reply

Hmm, maybe. Am I hearing that this could be a possible future functionality rather than something that's available now?

mark October 27, 2015 at 4:22 pm • Reply

It's available now.

Steve October 27, 2015 at 8:34 pm • Reply

OK, great. So how do I do that Mark?

John June 22, 2016 at 5:28 pm • Reply

Good day to all. I just want to ask if it is ok to put "/xmlrpc.php" on "Immediately block IP's that access these URLs". What would be the consequences?

Brian August 16, 2016 at 9:04 am • Reply

the consequences are big red blocks of blocked transgressors in your Live Traffic view in WordFence. This subtly suggests possible Server overload as they look so frequent - but probably not as it's just WordFence displaying it's log lines for blocked IP's.

What does this mean?

This means that when an IP# is blocked for a WordFence transgression it is also blocked and logged and displayed for every other request too - not just the naughties.

Again, this makes many lines of big red warning blocks in the Live Traffic file.

Mike July 16, 2016 at 10:04 pm • Reply

# Deny access to xmlrpc.php file
<files xmlrpc.php>
order allow,deny
deny from all
</files>

Northumbrian August 16, 2016 at 8:58 am • Reply

+1 Mike for finally, after all the above posts, spelling out the precise [ergo functioning] .htaccess block.

I'm quite shocked how:

a) no poster above has bothered with that precision and
b) how no reader has yet bothered to ask about the half-started xmlrpc examples above.

Kudos.

jahill70 October 13, 2016 at 6:04 pm • Reply

The think the issue missed by the article is that these xmlrpc attacks effectively become a DoS unless blocked at the apache level. It seems only takes around three xmlrpc requests a second to bring a modern six-core ssd-based Wordpress server to its knees.

mark October 13, 2016 at 10:28 pm • Reply

In general it's a bad idea to install WordPress with just Apache. There are a huge number of bots out there and they'll connect to xmlrpc quite quickly and just consume all apache children or threads. This is really a flaw with apache's execution model. It uses one thread or process per connection. Nginx uses a more modern design with async IO and one thread can handle many (over 10,000) connections. So bots that hang around and consume connections are not a problem.

So on _every_ site you install, make sure you reverse proxy to Apache using Nginx or a similar server that uses an asynchronous IO model of execution. That will solve the issue you're having.

Mark.

Jacob May 10, 2017 at 8:39 pm • Reply

This is the issue I've been having, where certain sites on the server are getting hammered on the xmlrpc.php file. I've tried changing the ownership and permissions on that file to 000, but still getting hammered today. I guess I could try the .htaccess file method, but that can cause other issues as mentioned in the article.

My main questions are - Does specifying the rate limiting rules solve this issue? And why are the rate limiting rules set to 'unlimited' -> throttle, out of the box? I've updated mine to the suggested settings in the documentation, but I'm curious why they're set to unlimited - doesn't that mean they're effectively turned off??

Iosif December 14, 2016 at 7:01 am • Reply

Thanks for these info! I had a spammer sending mass spam via that xmlrpc file. I added the httaccess code and the plugin. Hopefully now we're clean. Is there any way that they got in somehow? I have htaccess protection for wp-admin too.

Troy Glancy February 24, 2017 at 3:55 pm • Reply

I've had it blocked (aka redirect) xmlrpc on my shared servers for over a year. The only IPs I allow are WordPress servers that way Jetpack will keep working for client. Best thing I ever did. When I blocked it server load dropped like a rock. This was also when the whole xmlrpc.php brute force issues were going on.

I have this code in my Apache config but you can put it inside your .htaccess too if you want to still use Jetpack.

I disabled pingbacks as well but if you don't want to block them just use

For the first line below

Order Deny,Allow
Deny from all
Allow from *.wordpress.com
Allow from 192.0.64.0/18
Allow from 185.64.140.0/22
Allow from 2a04:fa80::/29
Allow from 76.74.255.84
Allow from 76.74.255.85
Allow from 192.0.65.204
Allow from 192.0.65.205
Allow from 192.0.80.244
Allow from 192.0.80.246
Allow from 192.0.96.247
Allow from 192.0.96.248
Allow from 192.0.123.250
Satisfy All
ErrorDocument 403 http://google.com/

nonspin April 27, 2017 at 6:47 am • Reply

Here's a more elegant sulotion to whitelist
yourself and redirect everyone else trying to access it
to a 404-Page.

The below .HTACCESS module redirects everyone
trying to login via /wp-login.php or /wp-admin/
and/or utilizing /xmlrpc.php...

ONLY the following IP-Range is allowed:
123.120.
..
123.129.

RewriteEngine on
RewriteCond %{REQUEST_URI} ^(.*)?wp-login\.php(.*)$ [OR]
RewriteCond %{REQUEST_URI} ^(.*)?xmlrpc\.php(.*)$ [OR]
RewriteCond %{REQUEST_URI} ^(.*)?wp-admin$
RewriteCond %{REMOTE_ADDR} !^123\.12[0-9]\.
RewriteRule ^(.*)$ - [R=404,L]

.nonspin

Get the latest WordPress security updates and news

Sign up for WordPress security alerts, Wordfence product updates and security news via email.