You are reading a security plugin’s report, or your host’s access log, and one file keeps appearing: xmlrpc.php. It gets hit far more often than any real page, by addresses you do not recognise, and you have never knowingly used it. Someone online tells you to delete it. Someone else says that will break things.
Both are partly right. Here is what the file does, why attackers like it, what might still depend on it on your site, and how to switch it off without breaking anything you care about.
What XML-RPC is
XML-RPC is an old, simple way for one program to ask another to do something over the web. The request is a small XML document sent by HTTP POST, naming a method; the server runs it and replies in XML.
WordPress adopted it early, when blogging was young, and xmlrpc.php in the root of every WordPress install is the door those requests come through. It was built for two jobs.
- Remote publishing. Before the browser editor was pleasant to use, people wrote posts in desktop programs and phone apps and sent them to their blog. Those tools logged in and published through XML-RPC.
- Pingbacks. When one blog linked to another, it could send an automatic notice to the linked site, which would then check the link and show it as a comment.
Both made sense at the time. Today most people write in the WordPress dashboard, pingbacks mostly bring spam, and XML-RPC remains switched on by default largely so that older tools keep working.
The REST API replaced it
WordPress now includes the REST API, a more modern interface that speaks JSON over ordinary web addresses under /wp-json/. The block editor itself runs on it, and most current apps, plugins and integrations that talk to WordPress use it instead of XML-RPC. External tools can log in to it with application passwords, which WordPress lets each user create and revoke from their profile, without handing over the main password.
That is why, for most small business sites, XML-RPC is a leftover rather than something in daily use. The WordPress REST API handbook covers the replacement if you or your developer want detail.
Why attackers aim at xmlrpc.php
Our guide to WordPress brute-force attacks mentions that this file accepts login attempts. The reason it is so attractive goes a little further.
Many password guesses in one request
XML-RPC has a method called system.multicall, which lets a client bundle many method calls into a single request. An attacker uses it to pack a long list of username and password pairs into one POST, each one an attempt to call a method that needs a login. The server checks every one and reports which worked.
This matters because a lot of login protection counts requests, or watches wp-login.php. One request containing a batch of guesses can slip under limits that were set with the normal login form in mind, unless your security tool understands XML-RPC specifically.
Pingback abuse
When WordPress receives a pingback, it fetches the page that supposedly linked to it, to check the link is real. Attackers abuse this by sending a flood of fake pingbacks to many WordPress sites at once, all claiming to come from one victim’s address. Each site obediently requests the victim’s page, and the victim receives traffic from a large number of ordinary servers. Your site becomes an unwilling helper in someone else’s denial-of-service attack.
Load, even when nothing gets in
Every XML-RPC request starts WordPress up. A steady stream of them uses PHP workers and database time on your hosting, which on a small plan can slow the site for real visitors even when every guess fails.
What might still depend on it
Check this before blocking anything. These are the usual candidates, and you should confirm each one on your own site rather than assume.
- Jetpack. Jetpack has historically used
xmlrpc.phpfor its connection to WordPress.com. If you use Jetpack, check its current documentation, or test carefully after blocking, because a broken connection can quietly stop features such as stats or backups that come through it. - Mobile and desktop publishing apps. Some apps, especially older ones and older versions, log in through XML-RPC. If anyone on your team posts from a phone or a desktop editor, find out which app and test it.
- Older publishing and syndication tools. Some services that post to WordPress automatically, or pull content from it, were built on XML-RPC and never moved.
- Pingbacks. If you want to receive pingbacks from other blogs, they need this file. Most business sites do not.
If none of these apply, and in most small business sites none do, you can block it. If one does apply, you still have options: some tools let you allow only the addresses that need it, which a developer or your host can set up.
Ways to disable it
A plugin or a security plugin setting
The easiest route is a small plugin built only to disable XML-RPC, or the option inside a security plugin you already use. Wordfence, for example, has a setting to switch off XML-RPC authentication. Read what each option actually does. Some disable only the methods that need a login, which stops password guessing but still lets the file answer other requests such as pingbacks. Others block it more completely.
WordPress itself has a filter, xmlrpc_enabled, that many of these plugins use. Turning it off switches off the logged-in methods. It does not stop requests from reaching the file, so WordPress still starts up for each one.
A server rule
Blocking the file at the web server is more thorough, because the request is refused before WordPress loads at all. That is the better choice if load is your problem.
On Apache (common on shared hosting and cPanel or Plesk servers), a rule in the .htaccess file in your site’s root does it:
<Files xmlrpc.php> Require all denied </Files>
On Nginx, the equivalent goes in the site’s server block:
location = /xmlrpc.php { deny all; }
Back up .htaccess before editing it. A typing mistake in that file can take the whole site down with a server error, so keep the old copy ready to put back. If you have one, try the change on a staging site first.
Your host or firewall
Many managed WordPress hosts block or filter xmlrpc.php already, or give you a switch in their dashboard. A web application firewall in front of the site, at your host or a service such as Cloudflare or Sucuri, can also block or rate-limit it. Ask your host what is already in place before adding your own rule.
How to test after blocking
- Open the file in a browser. Visit
yoursite.com/xmlrpc.php. When XML-RPC is open, WordPress normally replies with a short message saying the XML-RPC server accepts POST requests only. After a server block, you should see a 403 Forbidden page instead. A plugin that only disables logged-in methods may still show the original message, which is expected. - Check from the command line, if you are comfortable with it. Sending a POST request that calls
system.listMethods, using a tool such as curl, shows whether the server still answers XML-RPC calls at all. - Test what depended on it. Check the Jetpack connection status in your dashboard if you use Jetpack, publish a test post from any app your team uses, and confirm any automated posting service still works.
- Watch your logs for a few days. Requests will keep arriving, since bots do not read your settings. What should change is the response: refused, quickly, without WordPress doing the work.
Blocking XML-RPC is one layer, not the whole answer. Strong passwords, login limits and two-factor authentication still matter, because wp-login.php remains open to the same guessing.
If you would rather not touch it yourself
If you are unsure what on your site still uses XML-RPC, or you do not want to edit server files, this is the kind of check we cover in our website security service: finding what depends on it, blocking it in the right place, and confirming nothing broke afterwards.
Next in this series: Do You Need a WordPress Security Plugin?
