Table of contents15
The first time I looked at a client’s server logs, I thought the monitoring tool was broken. Thousands of requests to a single file — xmlrpc.php — hammering the site every hour, day after day, from IP addresses all over the world. The client had never heard of the file. They did not use it. Nobody on their team even knew what it was. And yet there it sat, wide open, absorbing attack after attack like a punching bag nobody had asked for. That wall of log entries is why I wrote this guide on how to disable XML-RPC in WordPress safely.
I’m Carlos Mendez, and I manage WordPress infrastructure for businesses that live or die by their uptime. That wall of log entries taught me something I now tell every site owner: XML-RPC is a door on your WordPress site that was installed for a world that mostly does not exist anymore — and attackers knock on it constantly because most people never lock it. The good news is that learning how to disable XML-RPC in WordPress safely takes about fifteen minutes, and for most sites nothing breaks.
Here is the fear I want to be straight about: XML-RPC lets attackers guess hundreds of passwords in a single request and turn your site into a weapon against other sites, all while your normal login protections watch helplessly. It bypasses the login-page defenses you carefully set up. If that sounds alarming, it should — but the fix is simple, reversible, and I will show you how to verify it actually worked.
In this guide you will learn what XML-RPC actually is in one plain sentence, why attackers love it so much, how to check whether you genuinely need it before touching anything, three safe methods to disable it ordered from strongest to simplest, how to verify it is really off, and exactly what to do if something breaks. This is for WordPress site owners who want to close a real attack vector without breaking their site. Ready? Let’s get started.
One honest note before we begin: “disable XML-RPC” sounds absolute, but the real world has edge cases. A small number of sites still need it for specific tools. That is why this guide starts with a decision step, not a delete step — and why every method here is reversible in under a minute.
What You Will Learn in This Guide
- What XML-RPC is, in plain language — and what it was originally built for
- Why attackers love it: password-guessing amplification and pingback abuse
- How to check whether your site actually needs XML-RPC before you disable it
- Three safe methods to disable it: server-level blocking, the PHP filter, and Nginx rules
- How to verify it is really off with a simple test
- What to do if something breaks — the quick undo for every method
Ready? Let’s get started.
What XML-RPC Is (One Plain Sentence)
XML-RPC is an old communication protocol that lets external programs talk to your WordPress site — publishing posts, uploading media, and managing content without using the dashboard. It lives in a single file called xmlrpc.php in your WordPress root, and it has been enabled by default since the early days of WordPress.
Think of it as a side entrance to your site built for robots. Back in the day, before WordPress had a modern mobile app or a proper REST API, desktop blogging tools and early mobile apps used this side entrance to publish posts remotely. It was genuinely useful — in 2010. The problem is that the side entrance is still there, still unlocked, on every WordPress site in the world, even though the modern tools that replaced it use a completely different door now.
Today, the official WordPress mobile app and modern integrations use the REST API, not XML-RPC. That means for the vast majority of WordPress sites in 2026, xmlrpc.php serves no legitimate purpose at all. It just sits there, answering requests from anyone on the internet — including the thousands of automated bots probing it every day. Which brings us to why attackers love it.
Why Attackers Love XML-RPC (The Two Attacks)
When I show clients their server logs, the reaction is always the same: disbelief, then a little nausea. Let me explain the two attacks that make this file so attractive, because understanding them makes the fix feel urgent in the right way — not panicked, just motivated.
Attack 1: Password Guessing at Industrial Scale
Your login page lets an attacker try one password per request. XML-RPC has a feature called system.multicall that lets a single request contain hundreds of login attempts bundled together. One HTTP request, hundreds of password guesses. Your login-attempt limiter — the thing counting failed logins on wp-login.php — never sees any of it, because the attempts never touch the login page. It is like a thief who discovered the building’s alarm only watches the front door while the loading dock stands open.
This is not theoretical. Brute-force botnets routinely hammer xmlrpc.php across millions of WordPress sites, trying common username and password combinations in bulk. Even if they never guess correctly, the sheer volume of requests can slow your site down — you are paying server resources to process attacks against a feature you do not use. Our guide to stopping brute-force attacks covers login-page defenses, but XML-RPC bypasses those entirely, which is why it needs its own fix.
Attack 2: Turning Your Site Into a Weapon (Pingback Abuse)
XML-RPC also handles pingbacks — the “someone linked to your post” notifications. Attackers abuse a method called pingback.ping to make your server send requests to a victim’s server, over and over, from thousands of compromised WordPress sites at once. Your site becomes an unwitting soldier in a distributed denial-of-service attack against someone else. You would never know it was happening unless you looked at your logs — your site just gets slower while it attacks a stranger.
Bonus Tip: even if you keep XML-RPC enabled for a legitimate reason, you can disable just the pingback feature under Settings, Discussion, by unchecking the pingback options. That single checkbox kills the DDoS-amplification abuse while leaving everything else working.
Disable XML-RPC in WordPress: Do You Actually Need It First?
Here is where most guides rush ahead and I want to slow down. Before disabling anything, take two minutes to check whether something on your site legitimately uses XML-RPC. Disabling a feature something depends on and then debugging the breakage is a miserable afternoon I would like to spare you.
Ask yourself three questions. First: do you or your team publish to WordPress from the official mobile app? The modern app uses the REST API, so the answer is almost certainly no — but if you use a very old version of the app, check. Second: do you use any remote publishing tools, desktop blog editors, or automation services that specifically mention XML-RPC? Most modern ones switched to the REST API years ago. Third: do you rely on pingbacks or trackbacks — those “linked to this post” notifications? If you turned those off years ago like most people, that is another no.
For the overwhelming majority of sites in 2026, the answer to all three is no, and you can disable XML-RPC with complete confidence. If you answered yes to any of them, do not worry — the section near the end covers your options, including how to restrict XML-RPC instead of fully disabling it. Either way, you are making an informed decision now instead of a blind one.
Method 1: Block It at the Server Level (Strongest)
This is my preferred way to disable XML-RPC in WordPress, and the method I use on every site I manage. Blocking xmlrpc.php at the web-server level means the request is rejected before WordPress — or even PHP — ever loads. During an active attack, that efficiency matters enormously: a PHP-level block still makes your server spin up WordPress for every malicious request, burning CPU on attacks. A server-level block drops them at the door for almost zero cost.
For Apache (.htaccess)
Open the .htaccess file in your WordPress root — back it up first, as always — and add this block before the standard WordPress rewrite rules:
# Block all access to xmlrpc.php
<Files "xmlrpc.php">
Require all denied
</Files>If your server runs the older Apache 2.2 syntax, use this version instead:
<Files "xmlrpc.php">
Order Deny,Allow
Deny from all
</Files>For Nginx
Nginx ignores .htaccess entirely, so add this location block inside your site’s server block, before any PHP processing directives, then test and reload Nginx:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}The access_log off and log_not_found off lines are a small kindness to yourself: without them, every bot probe writes a line to your logs, and you will drown in noise. With them, the attacks still get blocked — they just stop filling your log files.
To undo: delete the block you added and save the file. That is it. The whole method is one deletable block of text.
Method 2: Disable It With a PHP Filter (Simplest)
If editing server configuration files makes you nervous, there is a cleaner WordPress-native option: a single line of code that tells WordPress to switch XML-RPC off from the inside. Add this to a site-specific code snippet — ideally a small custom plugin or a child theme’s functions.php, so a theme update does not wipe it out:
add_filter( 'xmlrpc_enabled', '__return_false' );That one line hooks into WordPress’s own XML-RPC system and disables it cleanly. No plugin to install, no settings page, nothing to update. I prefer placing it so it survives theme changes — a tiny custom plugin with just this line is the most durable home for it.
The honest trade-off: this method still loads WordPress for every blocked request, so under a heavy automated attack it costs more server resources than the server-level block. For a typical small site that is not under active attack, the difference is negligible, and the simplicity is worth it. If your logs ever show xmlrpc.php getting hammered, upgrade to Method 1.
To undo: remove the line. XML-RPC comes back immediately.
Method 3: Restrict Instead of Disable (For Sites That Need It)
What if you checked and found you genuinely need XML-RPC — say, a legacy integration your business depends on? You do not have to choose between “fully open” and “fully closed.” The middle path is restriction.
The most practical restriction is IP allowlisting at the server level: block everyone except the specific IP addresses that need access. In .htaccess, that looks like a deny-all rule with explicit exceptions for your trusted IPs. The second option is disabling just the dangerous methods — particularly pingback.ping and system.multicall — while leaving the rest functional. And the third is rate-limiting requests to xmlrpc.php so automated abuse gets throttled before it matters.
My honest opinion: if you need XML-RPC for one legacy tool, the IP allowlist is the right answer. It keeps your integration working and closes the door to the entire internet. Whatever you do, do not leave it wide open “temporarily” — temporary has a way of becoming permanent, and botnets do not take holidays.
How to Verify You Disabled XML-RPC in WordPress Correctly
Disabling something without verifying is just hoping. Here are three concrete tests, easiest first.
Test 1: visit the file in your browser. Go to yoursite.com/xmlrpc.php. Before the fix, you would see the message “XML-RPC server accepts POST requests only.” After a proper server-level block, you should see a 403 Forbidden error. After the PHP filter method, you will typically see a blank page or an error message instead of the “accepts POST requests” text. Any of these means the door is closed.
Test 2: the command-line check. If you have terminal access, run a POST request against the file and look at the HTTP status code:
curl -s -o /dev/null -w "%{http_code}" -X POST https://yoursite.com/xmlrpc.phpYou want to see 403. That is the server refusing the request. If you see 200, your block is not in effect yet — double-check the placement of your rules.
Test 3: watch your logs for a day. After blocking, check your access logs for xmlrpc.php entries. You will still see bots trying — that never stops — but every attempt should now end in a 403 instead of a 200. The attempts become harmless noise instead of processed attacks. That log check is also how you will notice if something legitimate was using the file: a real integration will show up as a blocked request from a recognizable service, and you can allowlist it.
What to Do If Something Breaks
Let me save you the panic I have seen in others: every method in this guide is reversible in under a minute. If something stops working after you disable XML-RPC — a mobile app cannot connect, an integration fails, scheduled posts misbehave — do not debug for hours. Just undo the change first, confirm the problem goes away, and then investigate calmly.
The undo for each method: delete the .htaccess or Nginx block (Method 1), remove the filter line (Method 2), or loosen the IP allowlist (Method 3). Then clear any caches and test the broken feature again. In my experience, genuine breakage from disabling XML-RPC is rare in 2026 — the REST API handles what the mobile app and modern tools need. When something does break, it is almost always a legacy integration, and the IP-allowlist approach from Method 3 is the permanent fix: the integration keeps working, the rest of the internet stays out.
Note: if your site was already compromised before you disabled XML-RPC, closing this door does not evict an attacker who is already inside. Disabling XML-RPC is prevention, not cleanup. If you suspect a hack, work through our WordPress hacked recovery guide to clean the site first, then apply this guide to keep it clean.
Disable XML-RPC in WordPress: Frequently Asked Questions
Will disabling XML-RPC break the WordPress mobile app? No — not the modern app. The official WordPress mobile app has used the REST API instead of XML-RPC for years. If you are running a very old app version, update the app rather than keeping XML-RPC open. After disabling, open the app and confirm you can still manage your site.
Does disabling XML-RPC break Jetpack? Modern Jetpack versions communicate primarily over the REST API, so most sites see no impact. If you use an older Jetpack setup or a specific feature that still needs XML-RPC, use the IP-allowlist approach from Method 3 instead of a full block.
Which method is best: .htaccess, the PHP filter, or Nginx rules? Server-level blocking (.htaccess for Apache, location block for Nginx) is the strongest because it rejects requests before PHP loads, which matters most during active attacks. The PHP filter is the simplest and is perfectly fine for sites not under heavy attack. Use the strongest method you are comfortable maintaining.
How do I know if bots are attacking my xmlrpc.php right now? Check your server’s access logs and search for “xmlrpc.php”. On an unprotected site, you will typically find hundreds or thousands of entries. After blocking, you will still see the attempts — bots never stop trying — but they will all end in 403 responses instead of being processed.
Is disabling XML-RPC enough to stop brute-force attacks? No — it closes one major bypass route, but attackers can still target your login page directly. Pair this fix with login-page defenses: strong passwords, login attempt limiting, and ideally two-factor authentication. Our brute-force protection guide covers the login page side of the battle.
Final Thoughts
There is something satisfying about this particular fix. Most security work is ongoing — updates forever, monitoring forever, vigilance forever. Disabling XML-RPC is one of the rare exceptions: a fifteen-minute change that permanently removes an entire attack surface. The bots will keep knocking on that side entrance for years. They will just never get an answer again.
You now know what XML-RPC is, why attackers love it, how to check whether you need it, three safe methods to disable it, how to verify the fix with real tests, and how to undo everything in a minute if something breaks. That is the complete job — no loose ends, no hoping.
The honest line: this closes one door, and a secure site needs all of them closed. Keep going with the fundamentals — locked-down file permissions, hardened configuration files, and a safe update routine — and your site becomes the kind of target attackers skip in favor of easier prey. That is the whole game: be harder to hack than the next site.
Did your logs show the xmlrpc.php hammering I described? Check them and tell me what you found in the comments — I read every one.
Published: October 18, 2026 · Updated: October 18, 2026 · By Carlos Mendez
