What is XML-RPC? It’s an older way for apps to talk to WordPress, using a file called xmlrpc.php. Most small business sites can disable it, and I’d recommend doing so if you don’t use Jetpack or an older publishing app. First, check whether anything you rely on still needs it.
What is XML-RPC in WordPress?
XML-RPC is an old remote-procedure-call protocol: an app sends XML in an HTTP POST request, and WordPress carries out an action. WordPress exposes it at /xmlrpc.php. It’s been enabled by default since WordPress 3.5, released in 2012.
It gave apps and other sites a way to publish posts, edit content and manage a site remotely. It also powers pingbacks and trackbacks. That made sense when publishing from a separate app was harder to do any other way.
These days, the REST API, included in WordPress core since version 4.7, does most of that work. The official WordPress mobile app can use application passwords and the REST API. So don’t assume that using your phone to publish means you must leave XML-RPC open. Check the app you’re actually using.
There’s a catch, though. Jetpack still uses XML-RPC for parts of its connection to WordPress.com. Some older desktop blogging tools, IFTTT/Zapier-style integrations and older Android or iOS publishing apps rely on it too. Old doesnt mean unused.
Why do bots hammer xmlrpc.php?
The attraction is system.multicall. It can pack hundreds of username-and-password attempts into one HTTP request. A login-attempt limiter that counts requests to wp-login.php may see none of those attempts, even while the bot is trying passwords through XML-RPC.
That’s the difference between an xmlrpc.php brute-force attack and the usual login-page brute force. The goal is the same: guess a working login. The route and how the guesses are bundled are different. Locking down your login page matters, but it doesn’t automatically cover this other route. Our guide to securing the WordPress login page covers the front door; XML-RPC needs its own decision.
There’s also pingback.ping. An attacker can abuse it to make your site send requests to a victim as part of a DDoS reflection attack, or to probe internal hosts. Not a feature most shop owners asked for.
One more wrinkle: XML-RPC accepts application passwords, and many 2FA setups don’t protect XML-RPC logins. Don’t treat a second step on your normal login screen as proof this endpoint is covered.
How to check if XML-RPC is enabled
Start with the quick check. Open https://yoursite.com/xmlrpc.php in a browser, replacing the domain with yours. If you see XML-RPC server accepts POST requests only., the endpoint is reachable. That’s a useful clue, not proof that every XML-RPC method or login is available: your browser sent a GET request, while XML-RPC uses POST.
If you’re comfortable in a terminal, ask the endpoint to list its methods:
curl -s -d '<?xml version="1.0"?><methodCall><methodName>system.listMethods</methodName></methodCall>' https://yoursite.com/xmlrpc.phpAnd if you have access to your server logs, look for repeated POST /xmlrpc.php entries from random IP addresses. That’s the noise bots make. A blocked endpoint might return a denial instead, which is exactly what you want if nothing uses it.
Should you disable XML-RPC?
For most small business sites: yes, disable it completely. If you edit your pages in WordPress, take orders through your shop and don’t connect an older publishing tool, you probably won’t miss it. I wouldn’t leave a spare entrance open just because it shipped that way.
Pause before blocking it if you use:
- Jetpack, which uses XML-RPC for parts of its WordPress.com connection.
- An older desktop or mobile app that publishes to your site.
- An older automation or other integration that depends on XML-RPC.
Not sure? Make a note of the apps that publish or sync content before changing anything. You can disable the endpoint, test those connections, then reverse the change if one fails. If someone else manages an integration for you, ask them first rather than discovering the break during a busy sales day.
How to disable XML-RPC in WordPress
Pick one method. You don’t need to stack every option below just to make the point. Server-level blocking is my preference because the request never reaches PHP; a plugin toggle is easier if editing server configuration isn’t your idea of a pleasant afternoon.
Block xmlrpc.php at the server
On Apache, add this to the site’s .htaccess file:
<Files xmlrpc.php>
Require all denied
</Files>On Nginx, the equivalent server configuration is:
location = /xmlrpc.php { deny all; }Have your host or site maintainer make that change if you’re unsure where the configuration lives. If you use Jetpack, don’t block XML-RPC outright unless you’re prepared for its connection to stop working. Allowlisting Jetpack’s IPs is another option, but it needs ongoing attention.
Use a code snippet or mu-plugin
This PHP filter disables XML-RPC methods that require a login:
add_filter( 'xmlrpc_enabled', '__return_false' );Important: it doesn’t shut off pingbacks. If you’re using this approach, remove the pingback methods as well:
add_filter( 'xmlrpc_methods', function ( $methods ) {
unset( $methods['pingback.ping'] );
unset( $methods['pingback.extensions.getPingbacks'] );
return $methods;
} );Put the snippet in a code-snippet tool or mu-plugin, not somewhere you’ll lose it during a theme change. Also, don’t expect the browser check above to show a blocked endpoint: this method changes what XML-RPC can do, rather than stopping the request at the server.
Use your security plugin or firewall
Most security plugins offer a disable-XML-RPC toggle. If you don’t touch server files, this is the simplest place to start. Turn it on, then test any app or integration you use. Read what the toggle actually blocks, since some approaches disable logins without removing pingback methods.
What if you need to keep XML-RPC on?
Keep it for a reason, not by accident. If Jetpack or an older app needs it, rate-limit requests at the firewall, use strong unique passwords and make sure your firewall covers /xmlrpc.php. Our Smart firewall service is relevant here; Login protection matters too, but check that your setup covers XML-RPC rather than assuming rules for wp-login.php will catch it.
After any change, publish a test post from the app you rely on and check the Jetpack connection if you use it. A setting isn’t finished until you’ve tested the thing it might break.
What disabling XML-RPC won’t fix
It won’t repair weak passwords or update an old plugin. It won’t stop bots finding usernames through the REST API, either; that’s a separate issue covered in our article on REST API user enumeration. XML-RPC is one door of several. Close it if you don’t need it, then keep up with the rest of the site.
The two-minute check to do today
Open your site’s /xmlrpc.php address. If you get the POST-only message, ask one question: what on my site still uses this? Check Jetpack and your publishing apps. If the answer is nothing, disable XML-RPC and test your normal posting routine. That’s a better use of two minutes than watching bots keep knocking on a door you never meant to use.