Skip to content
SecurityStu

Disable XML-RPC

Security Fundamentals · Updated Jul 2026

Imagine discovering a hidden backdoor in your WordPress website, one you never installed and have never used. That’s roughly the deal with XML-RPC: a feature you might never have heard of that could be your site’s Achilles’ heel. Here’s what it is, why it’s a risk, and how to turn it off cleanly.

XML-RPC illustration

The WordPress connector

XML-RPC is a feature that lets your WordPress site communicate with other apps and programs. Think of it as a universal translator: it helps WordPress exchange information with other software using a common format (XML) over HTTP. It was genuinely useful once, for things like updating your blog from a phone app before the modern REST API existed.

Technical details, quickly:

  • XML-RPC stands for XML Remote Procedure Call
  • It’s an API built into WordPress core
  • It encodes its calls in XML and uses HTTP as the transport
  • By default, it is turned on

The risks

To an attacker, XML-RPC is a special language for asking your website questions. Leaving it enabled is like leaving the door slightly ajar so they can peek inside: What usernames exist? What plugins are installed? Can I try a few thousand passwords?

The top two reasons keeping it enabled is a gamble:

Brute-force attacks. XML-RPC permits multiple authentication attempts inside a single request, which quietly defeats the request limits most sites rely on. It also has no inherent safeguards against brute-force attempts, so attackers can grind through credential combinations until something works.

DDoS amplification. Methods like pingback.ping and system.multicall let attackers flood a site with resource-heavy requests, or weaponize your WordPress site against other targets. Because multiple calls fit in one request, server-imposed rate limits don’t help much here either.

What you gain by disabling it

Beyond closing the attack surface above, there’s a performance bonus: less junk traffic hitting /xmlrpc.php means reduced server load and resources freed up for requests that matter. On high-traffic sites or small hosting plans, that’s noticeable.

What you might give up

  • Some plugin functionality. A small set of plugins still use XML-RPC for remote publishing, media sync, or backups. Check yours before you flip the switch.
  • Legacy integrations. Older third-party apps that never moved to the REST API will stop working.
  • Old themes and plugins. Rarely, an outdated component misbehaves with XML-RPC off and needs an update or a workaround.

In practice, most modern plugins and apps don’t rely on XML-RPC at all, and the ones that do usually have REST-based alternatives. If anything, disabling it pushes the ecosystem toward better practices.

How to disable it

Method 1: a dedicated plugin. If you’d rather not touch code, a maintained plugin like Disable XML-RPC does it in a few clicks.

Method 2: your security plugin. Many WordPress security plugins include this as a feature. Wordfence, for example, has a “Disable XML-RPC Authentication” option under Login Security.

Method 3: functions.php. One line at the end of the file does it:

add_filter( 'xmlrpc_enabled', '__return_false' );

For the strongest version of this, block /xmlrpc.php entirely at your web server, CDN, or WAF, so the requests never reach WordPress at all.

What I’d actually do

If you don’t actively use XML-RPC, disable it, ideally at the WAF level. It removes an entire class of brute-force and DDoS surface with basically no ongoing tradeoff. It’s one of the easiest security wins available to a WordPress site owner.

Want to see the attack side for yourself? Lucian Nitescu has a good writeup: Exploiting XML-RPC on WordPress.