There is a file sitting at the root of almost every WordPress site that most owners have never thought about: xmlrpc.php. It has been part of WordPress since the very early days, it still answers requests on millions of sites, and it is one of the most reliably abused entry points in the whole ecosystem.

The good news: for most modern sites, you can switch it off entirely and lose nothing. Let's cover what it does, why attackers are so fond of it, how to tell whether you still need it, and the right way to shut the door.

What XML-RPC actually is

XML-RPC is a remote procedure protocol from the early 2000s. It let external applications talk to WordPress before there was any other way to do so: desktop blogging clients publishing posts, mobile apps managing sites, and the pingback system that notified one blog when another linked to it.

For its era, it was genuinely useful. But WordPress shipped a modern replacement years ago: the REST API, built into core since WordPress 4.7 in 2016. The REST API covers most modern remote-access needs with better security granularity, and it is what most current tooling builds on, though a few notable integrations still rely on XML-RPC (more on Jetpack below). XML-RPC remains enabled by default largely for backward compatibility.

That combination, an aging protocol that is on by default and forgotten, is exactly the kind of thing attackers look for.

Why attackers love it

A second login door. XML-RPC accepts username and password authentication on many of its methods, giving attackers a way to guess credentials that many login-protection setups watching wp-login.php never see. For years the abuse was worse: a method called system.multicall let a single request bundle hundreds of credential guesses at once. WordPress core has since blunted that specific trick (once one authentication attempt in a bundle fails, the rest are refused without being checked), but the bots never got the memo. Automated credential-guessing traffic still hammers xmlrpc.php around the clock on any site that leaves it open.

Pingback abuse. The pingback feature can be weaponized in two directions. Attackers use it to make thousands of WordPress sites send requests at a victim site, a reflection attack where your site becomes part of someone else's DDoS. The same mechanism also gets used for probing and amplification against your own site.

Cheap reconnaissance and load. Even failed XML-RPC attacks cost you something. Every request spins up WordPress, loads PHP, and touches the database. A steady stream of automated probing against xmlrpc.php is wasted server capacity, and on a busy site that waste is measurable.

None of this requires a vulnerability in the traditional sense. It is the designed functionality being used at hostile scale.

Do you still need it?

Probably not, but check before you block. The honest inventory:

  • Jetpack: the big exception. Jetpack still uses XML-RPC for its connection to WordPress.com, so if you run Jetpack, do not block xmlrpc.php outright; you would break the connection.
  • Legacy mobile and desktop publishing apps: the old WordPress mobile apps and clients like Windows Live Writer used XML-RPC. Modern workflows use the REST API or the block editor directly.
  • Some remote management and migration tools: a number of services, mostly older ones, still authenticate over XML-RPC. Check the documentation of anything you use for remote site management before blocking.
  • Pingbacks and trackbacks: if you genuinely rely on receiving pingbacks, blocking XML-RPC ends that. On most modern sites, pingbacks deliver little beyond spam, and losing them is no loss.

A practical test: check your server access logs for POST requests to xmlrpc.php from services you recognize. If the only traffic hitting that file is anonymous probing from IPs around the world, and it usually is, you have your answer.

The wrong ways and right way to block it

You will find several methods in tutorials, and they are not equivalent.

The plugin filter approach. Plugins and code snippets that use WordPress's built-in xmlrpc_enabled filter only disable the subset of XML-RPC methods that require authentication. The file still answers requests, other methods remain reachable, and every probe still boots WordPress to be told no. It is a half measure.

The .htaccess approach. Denying access to xmlrpc.php at the web server level is better: requests get refused before PHP runs. This is a solid option when server-level blocking is what you have available. Its limits are operational: it protects only that one origin, it is easy to lose during migrations or misconfigure, and the requests still reach and occupy your server, just more cheaply.

Edge blocking. The strongest version is refusing XML-RPC traffic at the CDN edge, before it ever reaches your server at all. The attack traffic dies on infrastructure built to absorb it, your origin never sees the request, and there is nothing on the server to misconfigure.

On Levamo, this is a single switch. Sites fronted by our managed Cloudflare setup have a Block XML-RPC access toggle in the dashboard that drops WordPress XML-RPC requests at the edge, through the Enterprise Cloudflare CDN, specifically to prevent brute force and pingback abuse while taking that junk load off your server entirely. If you later adopt a tool that genuinely needs XML-RPC, it is one click to allow again, no server surgery involved.

Where this fits in your security posture

Turning off XML-RPC is one of the highest-ratio moves in WordPress security: meaningful attack surface removed, near-zero functional cost for a modern site, done in minutes. But it is one door in a building with several.

The same thinking applies to the rest: strong authentication on the login page, keeping plugins and themes patched, a web application firewall in front of the application, and backups you have actually tested. If your host handles security at the infrastructure level, most of this should be running for you already, XML-RPC control included.

Check whether anything you use still needs xmlrpc.php. If nothing does, close the door. The bots knocking on it will not miss you, and your server will not miss them.