WordPress XML-RPC Explained: Should You Disable xmlrpc.php?

On this page

1. What xmlrpc.php actually is
2. What still uses it
3. Why attackers like it
4. How to check whether you need it
5. Safe ways to disable or restrict XML-RPC
6. Test afterwards
7. Don't confuse it with the REST API
8. One small step in a bigger picture

If you've looked at your security plugin's reports or your hosting logs, you may have noticed a file called xmlrpc.php being hit again and again. It's a part of WordPress that most business sites no longer use, yet it's switched on by default and bots love it. Here's what it is, how to tell whether anything on your site still relies on it, and how to switch it off or restrict it safely.

What xmlrpc.php actually is

XML-RPC is an older way for other programs to talk to your WordPress site remotely: publishing posts, uploading images, reading comments and so on, by sending XML messages to a single file, xmlrpc.php, in your site's main folder. It dates from the days when people wrote blog posts in desktop apps and sent them to their site, and it has been enabled by default in WordPress for many years.

Today, most of that work is done by the WordPress REST API, a newer system used by the block editor and most modern plugins and apps. XML-RPC is still included for backwards compatibility, which is why it sits on almost every WordPress site, used or not.

What still uses it

• Jetpack: the Jetpack plugin has historically relied on XML-RPC to connect your site to WordPress.com for features such as stats, backups and downtime monitoring. Blocking xmlrpc.php completely can break that connection.
• Some mobile and desktop apps: older versions of the WordPress mobile app, and some third-party blogging or publishing tools, use XML-RPC to log in and publish.
• Pingbacks: the automatic notifications one WordPress blog sends another when it links to it travel over XML-RPC.
• Older integrations: a few auto-posting and remote management services still use it.

The block editor, WooCommerce, contact forms and most modern plugins don't need XML-RPC at all.

Why attackers like it

Password guessing at scale

XML-RPC accepts a username and password with each request, so bots treat it as a second login page. A method called system.multicall lets one request carry many calls at once, which attackers have used to try many passwords in a single request. Recent WordPress versions have reduced how far a single request can be abused this way, but xmlrpc.php remains a favourite target, and every request still loads WordPress and uses server resources. On budget shared hosting, a steady flood of these requests can slow the whole site.

There's another catch: some login protection, such as attempt limits, CAPTCHAs or two-factor authentication, only covers the normal wp-login.php page. Unless your security setup also covers XML-RPC, it can be a side door around those defences. The steps in how to secure your WordPress login work best when this side door is closed too.

Pingback abuse

The pingback feature makes your server send a request to whatever address it's asked to check. Attackers have abused this to get large numbers of WordPress sites to flood a victim with traffic, and to reveal a site's real server address when it's hidden behind a firewall or CDN. Your site ends up as a tool in someone else's attack, on your server's resources.

How to check whether you need it

1. Check your plugins: is Jetpack installed and connected? Does any other plugin describe a connection to an external service or app?
2. Ask how content gets published: does anyone post from a mobile app, a desktop editor or an automation tool rather than the dashboard?
3. List external services that publish to, back up or monitor your site, and check their documentation for XML-RPC requirements.
4. Look at your access logs in your hosting control panel. Large numbers of POST requests to xmlrpc.php from random IP addresses are almost certainly bots; regular requests from a known service suggest something genuine is using it.

For a typical brochure site, clinic site or WooCommerce store without Jetpack, the answer is usually that nothing needs it.

Safe ways to disable or restrict XML-RPC

Option 1: a security plugin setting

Most well-known WordPress security plugins include an option to disable XML-RPC entirely, or to switch off just its login methods or pingbacks. This is the easiest route for most site owners, and it's easy to reverse. Option names vary, so check your plugin's documentation.

Option 2: a server or firewall rule

Blocking xmlrpc.php before WordPress loads saves the most server resources, because bot requests are refused without running any PHP. On Apache or LiteSpeed hosting, a developer can add a rule like this to the .htaccess file:

<Files xmlrpc.php>
  Require all denied
</Files>

Nginx servers use an equivalent location rule, and cloud firewalls such as Cloudflare let you block or challenge requests to that path. Some hosts will add a block for you on request. A mistake in .htaccess can take the whole site offline, so take a backup first or ask your developer. See WordPress firewalls explained for how these layers fit together.

Option 3: restrict rather than block

If you use Jetpack or an app that needs XML-RPC, it doesn't have to be all or nothing. You can disable pingbacks only, rate-limit xmlrpc.php at the firewall, or allow only the services you rely on. Check Jetpack's current documentation before restricting anything, since its requirements can change.

Test afterwards

Whichever method you choose, check that nothing has quietly broken:

• Open the website and the dashboard, and save a test draft
• Check Jetpack's connection status, if you use it
• Try any app or tool that publishes to your site
• Confirm that backup, monitoring and auto-posting services still report normally over the next few days
• Watch your security logs: requests to xmlrpc.php should now be refused before they reach WordPress

If something stops working, undo the change and switch to restricting instead of blocking.

Don't confuse it with the REST API

Some guides suggest disabling the REST API at the same time. Be careful: the block editor, WooCommerce and many plugins depend on the REST API, and turning it off completely can break your dashboard and checkout. Restricting the REST API is a separate, more delicate job.

One small step in a bigger picture

Disabling XML-RPC reduces bot noise and closes a side door, but it won't protect a site with outdated plugins or weak passwords. Treat it as one item alongside updates, two-factor authentication, backups and a firewall. And if bots hammering xmlrpc.php make you suspect someone has already got in, work through the guide to finding and removing backdoors.

Want this handled for you? Security hardening, including XML-RPC, is part of my WordPress malware removal and security service, and ongoing checks are included in my WordPress maintenance plans.