Check your server access logs right now. Search for xmlrpc.php. I’ll wait.
If your WordPress site has been online for more than a week, you’ll find hundreds — maybe thousands — of POST requests hitting that file. Most of them aren’t from you. They’re from bots trying to brute-force their way into your site.
Every WordPress installation ships with a file called xmlrpc.php sitting in the root directory. It’s been there since before WordPress was even called WordPress. And for most sites in 2026, it’s nothing but an open door for attackers.
What is XML-RPC?
XML-RPC is a protocol that lets external applications communicate with your WordPress site. Think of it as a side entrance to your website — separate from your regular login page — that accepts commands over HTTP using XML-formatted messages.
Back in the early 2000s, this was genuinely useful. Internet connections were slow, offline blogging clients were popular, and people needed a way to publish posts without loading the full WordPress dashboard. XML-RPC made that possible.
WordPress enabled it by default starting with version 3.5 in 2012. The WordPress mobile app, Jetpack, and various publishing tools all relied on it.
But then WordPress introduced the REST API in version 4.4 (2015), and XML-RPC became the internet equivalent of a fax machine — still technically functional, but completely replaced by something better and safer.
Why should you care?
XML-RPC has three major security problems that make it a favorite target for attackers:
Brute force amplification. Here’s the dangerous part most people miss: XML-RPC supports a method called system.multicall that lets attackers bundle hundreds of login attempts into a single HTTP request. Your standard login page rate-limiting? Useless against this. An attacker can test 500 username-password combinations in one request, bypassing most brute force protection tools that count individual requests.
DDoS amplification via pingbacks. XML-RPC handles WordPress pingbacks — the system that notifies other sites when you link to them. Attackers exploit this by sending forged pingback requests through thousands of WordPress sites simultaneously, turning them into an unwitting botnet. Your site becomes a weapon used against someone else, and your server resources get eaten in the process.
Credential exposure. Every XML-RPC request that requires authentication sends the username and password in plain text within the XML body. The REST API uses OAuth tokens instead. That difference matters.
I’ve seen this firsthand. One client’s site was getting 4,000+ xmlrpc.php requests per hour from different IPs. Their shared hosting account was being throttled, and their actual visitors were seeing timeout errors. Blocking the file fixed it immediately.
The quick fix
You have three options, from simplest to most thorough:
Option 1: WordPress filter (functions.php or site plugin)
// Disable XML-RPC entirely
add_filter( 'xmlrpc_enabled', '__return_false' );This disables the XML-RPC methods inside WordPress, but the file still responds to requests — meaning your server still processes them before rejecting.
Option 2: Block at the server level (.htaccess for Apache)
# Block all access to xmlrpc.php
<Files xmlrpc.php>
Order Deny,Allow
Deny from all
</Files>For Nginx:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}This is better — it stops requests before WordPress even loads, saving server resources.
Option 3: Block at Cloudflare/CDN level
If you use Cloudflare, create a WAF rule to block all requests to /xmlrpc.php. This stops the traffic before it even reaches your server. Zero server load from attackers.
Important edge case: If you use the Jetpack plugin and it requires XML-RPC (older versions do), disabling it completely may break the Jetpack connection. Check if your version of Jetpack uses the REST API instead — most recent versions do.
The one-click solution
If server configs and code edits aren’t your thing — and they shouldn’t need to be just to secure a basic WordPress feature — OvKit handles this with a single toggle.
Go to Features → Security, flip the Disable XML-RPC switch, and it’s done. OvKit blocks the XML-RPC methods at the WordPress level, returns proper HTTP headers to bots, and handles the Jetpack compatibility check automatically.
What happens after you fix this?
Once XML-RPC is disabled:
- Brute force attempts via xmlrpc.php stop completely — attackers get a 403 or empty response instead of a login interface
- Server load drops — especially on shared hosting where thousands of bot requests were consuming PHP workers
- DDoS pingback amplification is eliminated — your site can no longer be used as part of a botnet
- Your security logs get quieter — making it easier to spot actual threats
What still works: the WordPress mobile app (uses REST API in recent versions), the Gutenberg editor (uses REST API), WooCommerce (uses REST API), and basically every modern WordPress integration. The REST API replaced XML-RPC for all practical purposes years ago.
FAQ
Is it safe to disable XML-RPC in WordPress?
Yes, for the vast majority of sites. Over 99% of modern WordPress sites have zero dependency on XML-RPC. The only potential issue: if you’re running a very old version of the Jetpack plugin, or using a legacy desktop publishing client like Windows Live Writer. If you’re not sure, disable it and check if anything breaks — you can always re-enable in seconds.
What’s the difference between disabling with a plugin versus .htaccess?
A plugin or filter disables XML-RPC at the WordPress level — PHP still loads and processes the request before rejecting it. The .htaccess method (or Nginx equivalent) blocks the request at the web server level before PHP even starts. The server-level block is more efficient, especially if you’re getting hammered by bots. For the best protection, block at your CDN or firewall level so the traffic never reaches your server at all.
Will disabling XML-RPC affect my site’s SEO?
No. XML-RPC has no connection to SEO. Search engine crawlers don’t use XML-RPC to index your site. Disabling it actually helps indirectly — if bot traffic was causing server slowdowns, your pages will load faster for real visitors and Googlebot alike.
Related reads: