If you look at the access logs of almost any WordPress site that has been online for more than a few months, you will find a steady stream of POST requests to a file called xmlrpc.php. On some sites it’s a few hundred a day. On others it’s tens of thousands, and those requests are often the reason a modest server suddenly runs out of PHP workers at three in the morning. Understanding XML-RPC in WordPress takes only a few minutes, and it helps you make a sensible decision rather than following a random checklist.
Most site owners have never knowingly used XML-RPC. It’s one of those parts of WordPress that sits quietly in the background, mostly forgotten, until it starts showing up in security scans and hosting complaints. So the question I get asked a lot is simple: should I turn it off?
The honest answer is “probably, but check first”. This article explains what XML-RPC is, why attackers like it so much, who still relies on it, and how to block or restrict it in a way that matches how your site is actually used.
What XML-RPC actually is
XML-RPC is a remote procedure call protocol. In plain terms, it lets another program talk to your WordPress site by sending structured XML messages over HTTP. The program asks the site to do something, such as publish a post, upload an image or list recent comments, and the site responds with XML.
WordPress added XML-RPC support very early, long before the REST API existed. Back then, people wrote blog posts in desktop editors like Windows Live Writer or MarsEdit and published them remotely. Mobile apps, pingbacks between blogs and services like Jetpack all used XML-RPC because there was nothing else.
Since WordPress 3.5 it has been enabled by default, and since WordPress 4.7 the REST API has existed alongside it. The REST API does almost everything XML-RPC does, in a more modern and more controllable way. But XML-RPC was never removed, because removing it would break older integrations that still depend on it.
All of this lives in a single file in the root of your WordPress installation: xmlrpc.php.
Why attackers love xmlrpc.php
There are three main ways XML-RPC gets abused, and understanding them helps you decide how aggressive to be.
Amplified brute-force attacks
The normal login form, wp-login.php, accepts one username and password per request. If an attacker wants to try a thousand passwords, they have to send a thousand requests. That’s slow, noisy and easy for login-limiting plugins to spot.
XML-RPC has a method called system.multicall. It lets a client bundle many method calls into a single HTTP request. Attackers discovered that they could put hundreds of wp.getUsersBlogs calls into one request, each with a different password. One request, hundreds of password guesses.
Many login protection plugins only watch wp-login.php, so these attempts slip straight past them. Even when they’re caught, the damage to server resources is already done, because each request makes WordPress load fully and run password hashing many times over.
Pingback abuse for DDoS
The pingback feature lets one blog notify another when it links to it. The receiving site then fetches the linking page to verify the link. Attackers can send forged pingback requests to thousands of WordPress sites, asking each one to “verify” a link on a target website. Every one of those sites then sends a request to the target. Your site becomes an unwitting participant in a distributed denial-of-service attack against someone else.
Pingbacks can also be used to probe internal networks, because your server makes outbound requests to whatever URL it’s given.
Resource exhaustion
Even when attackers aren’t guessing passwords successfully, the sheer volume of XML-RPC traffic eats PHP workers and CPU. On shared hosting or a small VPS, that can make the site slow or unavailable for real visitors. I’ve seen sites where xmlrpc.php accounted for more than half of all dynamic requests, none of them legitimate.
Who still needs XML-RPC
Before you block it, take stock of what might be using it. The list is much shorter than it used to be, but it isn’t empty.
- Jetpack. Jetpack’s connection to WordPress.com historically relied on XML-RPC. Newer versions use the REST API for much of their communication, but some features still call xmlrpc.php, and blocking it completely can break the connection or specific modules.
- The WordPress mobile apps. The official apps can use the REST API for sites connected through Jetpack or WordPress.com, but self-hosted sites without that connection may still use XML-RPC for logging in and publishing.
- Older desktop blogging clients. If anyone on your team still writes in an old desktop editor, it almost certainly uses XML-RPC.
- Some integrations and automation tools. A handful of older services, like certain social auto-posters, IFTTT recipes and legacy CRMs, publish through XML-RPC. Most have moved to the REST API, but not all.
- Pingbacks and trackbacks. If you actually want pingbacks from other blogs, you need XML-RPC. Most modern sites turn pingbacks off anyway because they attract spam.
If none of those apply, you can block XML-RPC completely. If one or two do, you can restrict it instead of turning it off.
How to check whether anything uses it
The best evidence is your own logs. Look at requests to xmlrpc.php over a week or two and check where they come from.
| <code>grep "xmlrpc.php" /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -20</code> |
|---|
That command lists the IP addresses that hit xmlrpc.php most often. If the top entries are random addresses from data centres around the world, that’s attack traffic. If you see Automattic’s IP ranges (Jetpack) or your own office IP, something legitimate is using it.
You can also look at user agents. Legitimate clients usually identify themselves clearly, for example “Jetpack by WordPress.com” or “wp-iphone”. Attack tools often send blank or generic agents.
Ask your team too. Someone might be using the WordPress app on their phone to approve comments, and they’ll be the first to complain if it stops working.
Option 1: Block XML-RPC completely at the server
Blocking at the web server is the most efficient method because the request never reaches PHP. WordPress doesn’t load, no database connections are made and no CPU is spent on password hashing.
On Nginx, add this inside your server block:
On Apache, add this to your .htaccess file above the WordPress rules:
If you use Cloudflare or another firewall in front of your site, you can create a rule that blocks requests to the path /xmlrpc.php. This is even better, because the traffic never reaches your server at all.
Option 2: Disable it inside WordPress
If you don’t have server access, you can disable XML-RPC from within WordPress with a filter. A tiny must-use plugin works well:
Be aware of what this filter does and doesn’t do. It disables the XML-RPC methods that require authentication, which stops the brute-force attacks from succeeding. But the file still loads WordPress for every request, so the server load from attack traffic remains. Pingbacks may also still work, depending on version.
Many security plugins offer a “disable XML-RPC” toggle that does roughly the same thing. It’s better than nothing, but server-level blocking is better still.
Option 3: Restrict instead of block
If you need Jetpack or the mobile app, you can keep XML-RPC open to the services that need it and block everyone else.
For Jetpack, you can allow Automattic’s published IP ranges and deny the rest. The ranges change occasionally, so check Jetpack’s documentation for the current list rather than copying an old blog post. An Nginx version looks like this:
The details of the fastcgi lines will depend on your configuration, so copy them from your main PHP location block.
Another approach is to keep XML-RPC enabled but remove the most dangerous methods. This snippet disables system.multicall and the pingback methods while leaving the rest working:
That kills the amplified brute-force technique and stops pingback abuse, while still letting single-call clients function. Combine it with a login limiting plugin that watches XML-RPC as well as wp-login.php, and with strong passwords and two-factor authentication on all admin accounts.
Don’t forget the pingback headers
Even with XML-RPC blocked, WordPress may still advertise it. It adds an X-Pingback header to responses and a link tag in the page head pointing to xmlrpc.php. Bots use these signals to find targets. Removing them is cosmetic, but it reduces noise:
Also turn off pingbacks and trackbacks in Settings, Discussion, by unchecking “Allow link notifications from other blogs”. That only affects new posts, so if you want to close them on existing posts, you can run a quick WP-CLI or database update, or use a plugin that bulk-edits discussion settings.
What happens after you block it
Once XML-RPC is blocked, a few things are worth checking over the next few days.
First, confirm the block works. Send a simple POST to the file and check the response:
You should get a 403 Forbidden. If you get a 200 with an XML response saying “XML-RPC server accepts POST requests only” or a fault message, the block isn’t active.
Second, watch your server load. On sites under constant attack, CPU usage often drops noticeably within hours. That’s a nice confirmation that the effort was worthwhile.
Third, check Jetpack, if you use it. Go to the Jetpack dashboard and run the connection test. If it reports problems, either allow Automattic’s ranges or use the restricted approach.
Fourth, keep an eye on your logs. Attack bots don’t give up just because they get a 403. They’ll keep trying for weeks. Turning off access logging for that location, as in the Nginx example, keeps your logs readable.
A note on the REST API
People sometimes ask whether they should disable the REST API for the same reasons. The answer is no. The block editor, many plugins and WordPress itself depend on it. Disabling the REST API breaks far more than disabling XML-RPC does.
The REST API also has better security characteristics. It doesn’t support multicall-style batching of login attempts, and authenticated requests use cookies with nonces or application passwords rather than sending a username and password in every request. Locking down specific endpoints, like user listings, is reasonable. Turning the whole thing off isn’t.
The decision in short
For most business websites I work on, the answer is clear: block xmlrpc.php at the server or firewall, remove the pingback headers and move on. Nobody notices it’s gone, and the server is quieter for it.
If you use Jetpack or the mobile app on a self-hosted site, restrict rather than block. Allow the services you need, remove system.multicall and pingbacks, and make sure every admin account has two-factor authentication.
Either way, don’t leave it wide open by default just because it came that way. XML-RPC made sense in 2008. Today it’s mostly a door that attackers use and owners have forgotten exists. Whatever you decide about XML-RPC in WordPress, make it a deliberate choice and write it down in your site documentation.
Frequently asked questions
Will disabling XML-RPC hurt my SEO?
No. Search engines don’t use XML-RPC to crawl or index your site. Pingbacks once had a small role in how blogs discovered each other, but they have no meaningful SEO value today.
Does WordPress plan to remove XML-RPC?
There has been discussion for years, but as of now it remains in core for backwards compatibility. Don’t wait for it to disappear. Decide for your own site.
Is the security plugin toggle enough?
It stops the brute-force attempts from succeeding, which is the most important part. But it doesn’t stop the requests from loading WordPress, so you still pay the server cost. If attack traffic is heavy, block at the server or firewall as well.
I blocked it and the WordPress app stopped working. What now?
Either connect your site to Jetpack so the app can use the REST API path, or switch to the restricted approach and allow XML-RPC only from trusted IP addresses. Using the browser-based admin on your phone is also perfectly workable for most tasks.
