One quiet file on your WordPress site lets an attacker test hundreds of passwords in a single request — and your login limiter never even notices. That file is xmlrpc.php, switched on by default on every WordPress install since version 3.5. Learning how to disable XML-RPC in WordPress takes about ten minutes, and for most sites it breaks nothing. The catch is the word “most”: disable it blindly and you can knock out Jetpack, your mobile app, or a remote publishing tool with no warning. This guide does it the safe way — check what depends on it first, then pick the method that fits you.
This step sits alongside the other hardening moves in our WordPress security pillar guide — disable XML-RPC, then keep going.
What Is xmlrpc.php in WordPress?
Think of xmlrpc.php as a back door your site left open for apps that needed to talk to it from the outside. XML-RPC is a remote procedure call protocol — a way for external software to publish posts, upload media, and check credentials without opening the WordPress dashboard. It dates back to WordPress 2.6, when bloggers used desktop apps to write posts offline and publish them remotely.
Today the modern WordPress REST API (introduced in WordPress 4.7) does everything XML-RPC does, better — and the block editor, WooCommerce, and plugin updates all use the REST API. Yet the old file is still there, still switched on, on every fresh install. That is the whole problem: a legacy feature you probably never use, sitting open to the entire internet.
The three things that still genuinely use it are Jetpack, the WordPress mobile app, and a handful of older remote publishing tools. If none of those apply to you, XML-RPC is pure risk with zero benefit. WordPress’s own brute-force guide says so plainly: “If you don’t use XML-RPC, disable it.”
Why Attackers Love xmlrpc.php: The XML-RPC Brute Force Attack
A normal brute-force attack against wp-login.php is noisy: one password guess equals one HTTP request, so a login limiter spots the pattern and locks the IP out after a few failures. XML-RPC has a trick that defeats that logic completely.
The trick is a method called system.multicall. It lets a caller bundle hundreds of method calls into a single HTTP request — designed so a mobile app could publish a post and upload media in one round trip. Attackers abuse it to pack hundreds of login attempts into one POST request. Your login limiter sees one request and does nothing. Sucuri documented this amplification attack back in 2015, and it still works in 2026 because the endpoint is still on by default.
How bad can it get? WP Maintenance Pro documented a real case in April 2026: 147,832 requests to xmlrpc.php in six hours, each carrying roughly 500 password guesses — around 74 million login attempts in a single afternoon. Every attempt spawned a PHP worker and hit the database, so the site slowed to a crawl before anyone realized what was happening. And the pingback.ping method can turn your site into an unwilling participant in a DDoS attack, flooding a victim site with verification requests. An open xmlrpc.php is not just your problem — it can be somebody else’s too.
Before You Disable XML-RPC: The 60-Second “What Breaks” Check
Do not skip this step. Disabling XML-RPC is safe for most sites, but “most” is doing a lot of work in that sentence. Run through this checklist first — it takes a minute and saves you from a broken Jetpack connection you only discover days later.
- Is Jetpack active? Open Plugins and look for Jetpack. It uses XML-RPC to connect your site to WordPress.com, powering stats, backups, and remote publishing. If you use Jetpack, do not fully block XML-RPC — jump to the Cloudflare rate-limit option below instead.
- Does anyone publish from the WordPress mobile app? The current app mostly uses the REST API, but older versions and some setups still rely on XML-RPC. If anyone writes posts from a phone, test carefully after making the change.
- Do you use a remote publishing tool? Desktop editors, some automations, and a few migration tools still connect this way. Check your plugins list for anything that says “remote publishing” or “WordPress.com connection.”
If the answer to all three is no, you can switch XML-RPC off with confidence. Either way, back up your site before editing server files — a typo in .htaccess can take a whole site down until it is fixed.
How to Disable XML-RPC in WordPress: 4 Methods, Ranked by Safety
There is no single “right” method — the best one depends on how comfortable you are with code and server files. They are ranked here from easiest to most thorough.
Method 1: Use a Plugin (Easiest — Best for Beginners)
Choose this if you just want the job done in two minutes with zero code. Install the free Disable XML-RPC-API plugin from Plugins > Add New, activate it, and you are done — it hooks into WordPress’s xmlrpc_enabled filter and switches off authenticated XML-RPC methods immediately. There is nothing to misconfigure, and deactivating the plugin instantly reverses the change.
The trade-off is honesty: a plugin filter only stops methods that require a login. The file itself still answers requests, and pingbacks still work. That is fine for stopping brute-force logins, the main threat — but it is not a complete shutdown. If you want the door actually closed, use Method 2 or 3.
Method 2: Block xmlrpc.php in .htaccess (Best for Apache / Shared Hosting)
If your host runs Apache — which covers most shared hosting, including Hostinger and Bluehost — this is the strongest simple option. A server-level block refuses the request with a 403 Forbidden before WordPress even loads, so no PHP runs, no database query happens, and bots get nothing at all. Add this to your .htaccess file in the site root, ideally above the # BEGIN WordPress block:
# Block XML-RPC completely
<Files xmlrpc.php>
Require all denied
</Files>
That is the Apache 2.4 syntax (Require all denied). Back up .htaccess before editing, and test your site immediately after saving. One misplaced character can white-screen your site, and the fix is simply restoring the backup.
Method 3: Nginx Location Block (Best for Nginx / VPS Servers)
If your server runs Nginx — common on VPS setups, Cloudways, and Kinsta — there is no .htaccess file, so the block goes in your server configuration instead. Add this inside your server block, then reload Nginx:
# Block XML-RPC completely
location = /xmlrpc.php {
deny all;
}
The = makes this an exact match, so only /xmlrpc.php is blocked and nothing else is affected. Like the .htaccess method, the request dies at the server level before WordPress loads. On managed hosting you may not have access to the Nginx config — ask your host’s support team to add the rule, or fall back to Method 1.
Method 4: The xmlrpc_enabled Filter in a Must-Use Plugin (Best for Developers)
This is the code method — and it comes with a caveat most guides gloss over. WordPress provides a filter called xmlrpc_enabled that switches off XML-RPC methods requiring authentication. The honest version is right there in WordPress’s own developer reference: “Contrary to the way it’s named, this filter does not control whether XML-RPC is fully enabled.” It does not stop pingbacks or other methods that do not need a login.
Still, it is a clean, dependency-free way to kill the brute-force vector. Put it in a must-use plugin so it loads automatically and survives theme updates — never in your theme’s functions.php, which gets overwritten on the next theme update. Create wp-content/mu-plugins/disable-xmlrpc.php (create the mu-plugins folder if it does not exist) with this content:
<?php
/**
* Plugin Name: Disable XML-RPC authenticated methods
* Description: Switches off XML-RPC methods that require a login.
*/
add_filter( 'xmlrpc_enabled', '__return_false' );
No activation needed — WordPress loads must-use plugins automatically. Remember the caveat: this is a half-measure by design. For complete protection, pair it with a server-level block from Method 2 or 3.
The 4 Methods Compared
| Method | Difficulty | What it blocks | Best for |
|---|---|---|---|
| Plugin (Disable XML-RPC-API) | Easy | Authenticated methods only | Beginners, quick fix |
| .htaccess block (Apache) | Medium | Everything — 403 before WordPress loads | Shared hosting, full shutdown |
| Nginx location block | Medium | Everything — denied at server level | VPS, Nginx servers |
xmlrpc_enabled filter (mu-plugin) | Medium | Authenticated methods only, pingbacks still work | Developers, code-only setups |
The pattern is simple: plugin and filter methods stop logins; server methods stop everything. If you do not need XML-RPC at all, a server-level block is the correct answer. If you are nervous about editing server files, the plugin is a perfectly good first step — you can always upgrade to a server block later.
If You Must Keep XML-RPC On: Rate-Limit It With Cloudflare
Sometimes you cannot switch it off — Jetpack is running, or your team publishes from the mobile app. That does not mean leaving the door wide open. The answer is rate limiting at the edge, so one IP can only make a small number of requests per minute.
If your site sits behind Cloudflare (the free plan works), create a WAF custom rule: when the URI path equals /xmlrpc.php, block the request — or rate-limit it to a handful of requests per minute per IP. You can also allowlist Jetpack’s IP ranges and block everyone else, keeping Jetpack working while shutting out the bots. WordPress’s own brute-force guide recommends exactly this: restrict XML-RPC and rate-limit it aggressively if you must keep it.
This pairs well with the other layers of a hardened login: a stronger login URL and limited login attempts mean an attacker who gets past the XML-RPC block still faces two more locked doors.
Prove It Worked: Test That XML-RPC Is Really Off
Never trust a setting you have not tested. Visit yoursite.com/xmlrpc.php in your browser. On a default WordPress site you will see “XML-RPC server accepts POST requests only.” After a server-level block, you should see a 403 Forbidden page instead. After the plugin or filter method, the message may still appear — that is expected, since the file still answers; the authenticated methods behind it are what got switched off.
For a real test, run this from a terminal:
curl -X POST -d '<methodCall><methodName>system.multicall</methodName></methodCall>' https://yoursite.com/xmlrpc.php
A blocked site returns a 403. A filter-only site returns an XML fault response instead of executing anything. Either way, no login attempts get through. Then check the things that matter: save a draft from the mobile app, confirm Jetpack still shows as connected (if you use it), and load your homepage.
Frequently Asked Questions
What is xmlrpc.php in WordPress?
xmlrpc.php is a file in every WordPress install that lets external apps publish posts, upload media, and verify logins remotely using the XML-RPC protocol. It has been enabled by default since WordPress 3.5. The modern REST API has largely replaced it, so most sites no longer need it — but it stays switched on unless you disable it.
Should I disable XML-RPC in WordPress?
For most sites, yes. WordPress’s own brute-force guide advises disabling it if you do not use it. The only reason to keep it is a real dependency: Jetpack, the WordPress mobile app, or a remote publishing tool. If you are unsure, use the plugin method first — it reverses instantly.
Will disabling XML-RPC break Jetpack?
Yes, it can. Jetpack relies on XML-RPC to connect your site to WordPress.com, so a full server-level block breaks Jetpack’s sync, stats, and backup features. If you use Jetpack, do not block xmlrpc.php outright — keep it on and rate-limit it with a Cloudflare WAF rule instead, or allowlist Jetpack’s servers and block everyone else.
How do I know if XML-RPC is enabled?
Visit yoursite.com/xmlrpc.php in your browser. If you see “XML-RPC server accepts POST requests only,” it is enabled. If you see a 403 Forbidden page, it is already blocked at the server level. For a deeper check, use the curl test above, or search your server access logs for xmlrpc.php requests.
Does disabling XML-RPC stop brute force attacks?
It stops brute-force attacks through XML-RPC — including the system.multicall trick that packs hundreds of guesses into one request. It does not stop attacks against wp-login.php itself, so it is one layer, not a complete defense. Pair it with a changed login URL, limited login attempts, strong passwords, and two-factor authentication. Our brute-force protection guide covers the full layered setup.
The Takeaway
xmlrpc.php is a door you probably never open — so stop leaving it unlocked for everyone else. Check what depends on it, pick your method, block it at the server if you can, and prove it worked with the curl test. Ten minutes of work closes the quietest brute-force hole on your site — and the bots will move on to someone who never read this guide. If hardening your site feels bigger than one article, our team can handle it — see our WordPress security services or get in touch.
