If you've never heard of XML-RPC, you're not alone. Most WordPress site owners have no idea this file exists, let alone that it's quietly sitting on their server as an open door for attackers. Yet it's one of the most commonly abused files in WordPress, and disabling it takes about five minutes.
Let's talk about what XML-RPC actually does, why it's a security risk for most sites, and exactly how to turn it off safely.
What Is XML-RPC in WordPress?
XML-RPC is a file (xmlrpc.php) that lets external applications talk to your WordPress site over HTTP. It was built years ago, before WordPress had a modern REST API, to support things like:
- Posting to your blog from a mobile app
- Using desktop blogging clients like the old MarsEdit or Windows Live Writer
- Enabling pingbacks and trackbacks between WordPress sites
- Connecting third-party services like Jetpack to your site
Sounds useful, right? The problem is that almost nobody uses these old-school tools anymore. WordPress now has a full REST API that handles most of these jobs better and more securely. But xmlrpc.php is still enabled by default on nearly every WordPress install, whether you need it or not.
Why XML-RPC Is a Security Problem
Here's the part that matters. XML-RPC isn't just unused, it's actively dangerous because of how attackers use it.
Brute Force Attacks Get Easier
Normally, a brute force attack against your login page means one guess per request. With XML-RPC's system.multicall method, an attacker can bundle hundreds of username and password combinations into a single request. That means your server processes hundreds of login attempts in one shot, which is far harder to detect and block than normal traffic. We covered the fundamentals of this kind of attack in WordPress Login Security: Simple Changes That Stop the Majority of Brute Force Attempts.
DDoS Amplification Through Pingbacks
The pingback feature can be weaponized too. Attackers send a request pretending your site wants to pingback a target URL, and your server does the work of hitting that URL for them. Do this across thousands of compromised WordPress sites at once, and you've got a distributed attack that uses innocent WordPress installs as the muscle. Your own server becomes an unwilling participant.
Constant Background Noise
Even if an attack never fully succeeds, xmlrpc.php gets hit constantly by bots scanning the internet for open doors. This creates extra load on your server, fills up your logs with junk, and gives attackers more surface area to probe for weaknesses.
Do You Actually Need XML-RPC?
Before switching it off, check if you rely on it. You likely need XML-RPC if:
- You use the Jetpack plugin
- You publish posts from a mobile app that specifically uses XML-RPC (rare these days, most use the REST API now)
- You have a custom integration that was built specifically to call xmlrpc.php
If none of that applies to you, and for most site owners it doesn't, you're safe to disable it.
How to Disable XML-RPC on WordPress
Method 1: Using a Security Plugin
The easiest and safest way is through a plugin you may already have installed.
- Wordfence: Go to Wordfence > All Options > Brute Force Protection, and check the option to disable XML-RPC authentication.
- iThemes Security: Under Settings, look for WordPress Tweaks and toggle off "Disable XML-RPC."
- Disable XML-RPC-API: A lightweight, dedicated plugin that does exactly one job, turns off XML-RPC completely, with zero configuration.
If you're already running a security plugin, this is the lowest-risk option because it doesn't touch your server files directly.
Method 2: Editing .htaccess (Apache Servers)
If you'd rather not add another plugin, you can block access at the server level. Add this to your .htaccess file:
# Block WordPress xmlrpc.php requests
<Files xmlrpc.php>
order deny,allow
deny from all
</Files>
This tells your server to reject any request to that file before WordPress even loads it, which is more efficient than a plugin-based block.
Method 3: Adding a Filter to functions.php
If you're comfortable editing theme files (always use a child theme, never edit a parent theme directly), you can add this snippet:
add_filter('xmlrpc_enabled', '__return_false');
This disables XML-RPC functionality without actually blocking access to the file itself. It's a decent middle ground, but the .htaccess method is generally stronger since it stops the request earlier.
Method 4: Selectively Disabling Just Pingbacks
If you still need XML-RPC for something like Jetpack but want to close the pingback loophole, add this to functions.php instead of fully disabling XML-RPC:
add_filter('xmlrpc_methods', function($methods) {
unset($methods['pingback.ping']);
unset($methods['pingback.extensions.getPingbacks']);
return $methods;
});
This keeps the door open just enough for the integrations you need, while removing the specific methods attackers abuse most.
How to Confirm It Worked
After making changes, test it. Visit yoursite.com/xmlrpc.php in your browser. If you see "XML-RPC server accepts POST requests only," that just means the file is reachable but you haven't tested the actual disabling yet. A properly blocked setup should return a 403 Forbidden error, or the file should refuse any functional requests. You can also use an online XML-RPC validator tool to send a test request and confirm nothing responds.
Why This Matters More Than You Think
Disabling XML-RPC isn't going to make headlines, and it won't feel like a big security win the way installing a firewall does. But it closes one of the most consistently exploited entry points in WordPress, for basically zero cost and no downside for most sites. If you're auditing your site's defenses, this belongs near the top of the list, right alongside checking your login page and reviewing your plugin list, topics we get into in The WordPress Security Checklist Every Site Owner Should Run Through Once a Quarter.
Good hosting environments often handle this kind of hardening automatically as part of managing your WordPress install, but if you manage your own server or you're not sure what's been configured, it's worth checking yourself. A managed web application firewall can also help catch abusive XML-RPC requests before they ever reach your application, which adds another layer if you're not ready to disable it outright.
The Takeaway
Unless you're actively using Jetpack or a legacy publishing tool that depends on it, there's no good reason to leave xmlrpc.php exposed. Pick whichever method fits your comfort level, plugin, .htaccess, or functions.php, test that it worked, and cross one more attack vector off your list. It's a small change that removes a surprisingly common target.
