WordPress XML-RPC is a system designed to make it easy for other systems to communicate with a WP site.
Weβre going to explore what it is, what it lets you do, and why you might want to disable, and how.
Just what does WordPress XML-RPC do for you?
It provides an interface to communicate with your WordPress site.
Itβs been turned-on by-default since WordPress 3.5 (circa 2012) and where itβs used will vary, from your iOS App, to letting other websites send βpingbacksβ when they link to your articles.
But the need for XML-RPC has dramatically decreased, especially since the newer WP REST API has been built.
Thereβs no doubt about it, XML-RPC is a major API component of a WordPress site and depending on how your site is structured you may be using it and not even know. An example of this is the JetPack plugin (at the time of writing) that uses the XML-RPC API extensively.
Can someone attack my XML-RPC?
One of its features is the ability to send multiple commands using a single HTTP request. Handy, but not really when one of those commands could be a login authentication.
This means that with a single web request, an attacker can try hundreds of login username/password combinations. There isnβt any real-world application of such a feature for most of us. So thereβs no good reason to leave this attack vector lying open unless we really need to.
Is XML-RPC being used on my site?
The only way to know this is to
- Examine your plugins and theme and see whether they make use of XML-RPC in their spec. An example of this is JetPack which uses XML-RPC extensively.
- Monitor traffic on your site We outline this below, under option #2. Shield has an integrated Traffic Monitor, and this will let you see hits to your XML-RPC and from there determine if itβs actually in-use.
Can you disable XML-RPC?
Itβs technically possibly to disable it. But before you set about doing that, you need to determine if your site uses it or not (see later on under the section with disabling XML-RPC using Shield)
Letβs assume that youβve done the research and decided that your site doesnβt need XML-RPC. Can you, and should you, disable it? Our opinion is that if itβs not being used, then thereβs no upside to keeping it around.
If youβve decided to disable it, weβre going to outline 2 of ways you can go about it.
- Blocking XML-RPC using CloudFlare (the easiest).
- Blocking XML-RPC using Shield Security Pro.
The 1st one is ideal because it blocks traffic before requests even touch your web server. Weβve been recommending CloudFlare for everyone years, for every domain they manage. If youβre on CloudFlare already, this will take only a few minutes to setup.
#1 β Steps to block WordPress XML-RPC using CloudFlare
All free CloudFlare plans come with 5 firewall rules, so there is no cost to you for creating the following rule:
- Log into CloudFlare and select the domain you want to manage.
- Select βFirewallβ from the main navigation.
- Click the button to create a Firewall rule
- Give your new rule a name β any name will do.
- Now you need to create rules to match requests that are specific to XML-RPC:
- Field: URI Path
- Operator: contains
- Value: /xmlrpc.php
- You can also add the following rule, though itβs not required. Beside the first rule you created, click the βAndβ button (not the βOrβ!). If you click βOrβ, youβre in trouble.
- Field: Request Method
- Operator: equals
- Value: POST
- Then you need to choose the action that CloudFlare will take. We recommend choosing βBlockβ.
- Then click βSave and Deployβ

And youβre done! XML-RPC requests to your WordPress site will be intercepted and blocked before they even reach your WordPress site.
Please note that CloudFlare is a powerful system and creating the Firewall blocking rule, incorrectly, could break normal access to your site. If you notice anything strange or broken as a result of this, you can delete the rule you just created and return the site back to normal.
#2 β Steps to block WordPress XML-RPC using Shield Security
Shield Security also provides the option to block any XML-RPC requests made to your site.
You can use Shield Security Pro to determine whether your site is actually using XML-RPC.
- Under the βBots & IPsβ security zone within Shield, find the option βXML-RPC Accessβ under the Bot Actions section and turn this on to βActivity Log Onlyβ
- Monitor your WP Activity Log for a few days to see if there are any legitimate requests to your XML-RPC. If youβre seeing traffic there and itβs legitimate, you may want to hold off disabling it. Otherwise proceed to the next steps.
- Navigate to the main Security Zones menu > Firewall Zone > API & XML-RPC
- Click to turn-on the option that disables XML-RPC, and save.
How to verify your WP XML-RPC is disabled
After performing either of the steps above, you can verify XML-RPC is disabled quite easily.
If you donβt know the URL of your XML-RPC, you can find it by:
- Browsing to your WP Login URL. e.g. https://www.example.com/wp-login.php
- Remove βwp-login.phpβ from the URL and replace it with βxmlrpc.phpβ
With your XML-RPC URL, go to this site and test whether it can communicate with it. Youβll discover in a few seconds whether or not youβve correctly disabled access to it.
Should you use Shield, or CloudFlare to disable XML-RPC?
We could obviously say βShield is bestβ because we want you to think you canβt live without us, but in this case, CloudFlare is the better solution. Hereβs whyβ¦
CloudFlare acts like a proxy, and this means that traffic is routed via their servers. If anyone tries to access your XML-RPC endpoint and you have the CloudFlare rule in-place, the request wont even register on your website. With CloudFlare, youβre blocking traffic long before it even touches your WordPress site. This is the best way to stop traffic you donβt want.
But it does no harm to use both settings. In-case you need to pause CloudFlare at a future date, Shieldβs protection will kick-in and protect your site, too.
Comments and Feedback
Weβve covered in this article what XML-RPC is, why it might be used, and how you can disable it completely, and verify itβs been disabled.
Remember to always assess whether you need it disabled, and you follow the instructions carefully when doing so.
If you have any suggestions on this or improvements that can be make, please let us know in the comments below.
Great article. Thanks for the telling us about that firewall rule
Hi Paul thanks for another clear explanation and appropriate action process.
I wonder if you would consider recommending your top five Free Cloudlflare Firewall rules or maybe a top seven for those that will need to avoid any of the early items in the list of five.
I’ve found great lists of Page Rules to use on our typical WordPress websites, but less so with CF Firewall rules.
Many thanks.
Hey, thanks for the post! I used it to block xmlrpc.php on tons of my sites.
By using the AND operator and blocking “only” Post Requests the xmlrpc.php is still available via browser. I am not sure if this is a problem?
Lets say some “bad guy” starts to send Post Requests to the xmlrpc.php, he gets a 403 and Cloudflare will cover the traffic and server load then?
Thanks
Nils