Open your WordPress site in a browser, append /xmlrpc.php to the URL, and hit enter. If you see "XML-RPC server accepts POST requests only.", congratulations, your site is broadcasting a 21-year-old endpoint that attackers use to amplify brute-force attacks, fingerprint logins, and on a bad day point your server at someone else's. The fix is one line of PHP. We are going to walk through what XML-RPC is, why WordPress kept it, what specifically goes wrong, and the four ways to switch it off, ranked from weakest to strongest.
What XML-RPC is, briefly
XML-RPC is a remote-procedure-call protocol from 1998. It sends an XML payload over HTTP, lets the client call a named function on the server, and gets back a structured response. WordPress shipped XML-RPC support in 2003, when the alternative was either FTP-ing PHP files or using slow dashboard forms. For its time it was elegant.
It powered three big things: posting from desktop blog clients like Windows Live Writer, pingbacks and trackbacks between blogs, and the early Jetpack feature set that lets WordPress.com talk to a self-hosted site. For roughly a decade, XML-RPC was the only sanctioned way for software outside your wp-admin to read or write content on your site.
Then in 2016, WordPress 4.7 introduced the REST API. The REST API is faster, more secure by default, uses standard JSON, supports OAuth and application passwords, and is what every modern integration speaks. XML-RPC is still in core for backwards compatibility, but no actively maintained tool needs it. The Gutenberg editor uses REST. The mobile apps use REST. New Jetpack features use REST.
The protocol stuck around the way old freeway exits stick around: nobody is using them on purpose, but you cannot quite tear them out without breaking a few cars.
Why xmlrpc.php is a problem in 2026
The endpoint, https://yoursite.com/xmlrpc.php, is enabled by default on every WordPress install. It is one file in your wp root. Removing it does not work, the next core update puts it back. The problem with leaving it on is not theoretical, it is one of the most-attacked files in the entire ecosystem.
1. Brute-force amplification. The wp.getUsersBlogs method takes a username and password as parameters. Each request tries one credential pair, and the server responds yes or no. Worse, the system.multicall method lets the attacker bundle hundreds of login guesses into a single HTTP request. So a bot can try 500 passwords with one request, blow through naive fail2ban rules, and not even show up as 500 entries in your access log. We have walked into client sites where xmlrpc.php was eating more bandwidth than the homepage, all of it brute-force.
2. Username enumeration. Even when login fails, the response leaks information. Send a guess at wp.getUsersBlogs with username admin and any password, and the fault code tells you whether admin exists. That is a free reconnaissance tool for the next stage of attack.
3. Pingback DDoS reflection. The pingback.ping method is meant to tell another blog "hey, I linked to you." Your server fetches the URL the caller specifies, to validate the link. That means an attacker can ask thousands of WordPress sites to all hit one victim URL at once. Your site becomes part of a distributed denial-of-service attack without anyone touching the wp-admin login. Akamai documented this exact pattern at scale years ago, and it has not gone away.
4. SSRF and internal port scanning. Because pingback makes the server fetch arbitrary URLs, attackers have used it to probe internal networks the public internet cannot reach, things like http://192.168.0.1/admin or http://localhost:9200 for an Elasticsearch instance the operator forgot to lock down. The WordPress server becomes a proxy for the attacker.
5. Plugin attack surface. Plugins can hook into XML-RPC to add their own methods. Every added method is another exposed function on a public endpoint. Several historical CVEs in major plugins were exploitable specifically because XML-RPC was on.
Disabling XML-RPC closes all five of these in one move. The only cost is that you cannot ping or trackback to other blogs, a feature that has been spam-poisoned for so long that most sites disabled it anyway.
Will anything break if I turn it off?
Probably not. The honest list of things that still need XML-RPC in 2026:
- The first-time Jetpack connection on very old setups — modern Jetpack uses REST, but if you are connecting a site running an older Jetpack version, the handshake can still try XML-RPC. Update Jetpack first.
- A handful of legacy desktop blogging clients — Windows Live Writer, Open Live Writer, MarsEdit on certain versions, third-party niche apps. If you still post from one of these, you will need to keep XML-RPC on or migrate to the WordPress admin or the REST-based mobile app.
- Pingbacks and trackbacks — disabling them is widely considered a feature, not a loss.
If you are unsure, the safe sequence is: take a backup, disable XML-RPC, use the site normally for a week. If nothing complains, you are done. If a specific tool breaks, you have a much narrower question, do I need this tool, or do I need this tool with XML-RPC.
The one-line fix, and three stronger ones
Four layers, weakest to strongest. Apply at least one. Apply more than one if the site is actively targeted.
Method 1, the PHP filter (the one-line fix)
Open wp-config.php, or, better, a small mu-plugin file in wp-content/mu-plugins/, and add:
add_filter( 'xmlrpc_enabled', '__return_false' );That is it. __return_false is a WordPress core helper. The filter tells WordPress to refuse all XML-RPC method calls. Requests to xmlrpc.php still get a response, but it is a clean "XML-RPC services are disabled on this site." rather than an executable surface.
Pros: zero dependencies, survives core updates, two seconds to apply, easy to revert. Cons: PHP still has to boot to return that disabled message. If you are being hammered, your server is still spending CPU on every malicious request.
Why a mu-plugin instead of functions.php: themes change, must-use plugins do not. Putting security filters in the theme means a theme swap silently re-enables XML-RPC. A two-line mu-plugin file outlives all of that.
Method 2, block at the web server (nginx)
Add to your server or location block:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
return 444;
}Return 444 is nginx's "close connection without response," which makes scanners give up faster than a clean 403. Requests never reach PHP, so the CPU cost is zero. This is the version we put on every WordPress site we host.
Method 3, block at the web server (Apache, .htaccess)
If you are on Apache, add this to .htaccess in the WordPress root, before the WordPress rewrite block:
<Files xmlrpc.php>
Require all denied
</Files>Same outcome as the nginx version, requests are rejected before PHP runs. On older Apache 2.2 you would use Order allow,deny / Deny from all instead, but anything currently supported is on 2.4.
Method 4, allowlist if you genuinely need it
If a specific service must call xmlrpc.php, do not leave the door open to the whole internet. In nginx:
location = /xmlrpc.php {
allow 198.51.100.42;
deny all;
}Replace the IP with the actual source. Jetpack publishes its IP ranges if that is your use case. This way the endpoint exists only for traffic you sanctioned.
How to verify it actually worked
Three quick checks from your laptop:
- Open
https://yoursite.com/xmlrpc.phpin a browser. You should see either a blank 403/444 (web-server block) or a short XML message about XML-RPC being disabled (PHP filter). If you see "XML-RPC server accepts POST requests only.", the endpoint is still live. - From a terminal:
curl -d "<methodCall><methodName>system.listMethods</methodName></methodCall>" https://yoursite.com/xmlrpc.php. With XML-RPC disabled you get an empty array or a 403. With it enabled you get back a long list of method names includingwp.getUsersBlogsandpingback.ping. - Check your access log over the next 24 hours. The xmlrpc.php hits should drop from "hundreds to thousands per day" to either zero or all 403/444. If they keep returning 200, your block is in the wrong file.
While you are in there, four more cheap WordPress hardening wins
If you are editing wp-config or .htaccess anyway, these five-minute additions are worth doing in the same session. We cover the broader pre-launch inventory in our technical SEO checklist, but on the security side specifically:
- Disable file editing from the dashboard. Add
define( 'DISALLOW_FILE_EDIT', true );to wp-config.php. If an attacker hijacks an admin account, they cannot just paste a webshell into your theme. - Force SSL on the admin.
define( 'FORCE_SSL_ADMIN', true );in wp-config. Already on for any reputable host, but worth checking. - Block the WordPress REST API user enumeration endpoint for unauthenticated requests.
?rest_route=/wp/v2/usersleaks the same usernames XML-RPC does. Filter it or restrict it to logged-in users. - Rename or rate-limit
/wp-login.php. Either at the web server or with a small login-hardening function. The combination of disabled XML-RPC plus rate-limited wp-login.php closes the two main brute-force doors.
What about the security plugins that "disable XML-RPC"?
Wordfence, iThemes Security, Sucuri, All In One WP Security, every major security plugin has a toggle for this. They all do essentially what Method 1 does, set the same filter. The difference is overhead. A full security plugin loads tens of thousands of lines of PHP on every request to flip one boolean. If that is the only thing you wanted, the one-line filter does it without the plugin tax. The plugins justify their existence when you also want firewall rules, malware scanning, login captcha and the rest. For just the XML-RPC piece, the filter wins.
This is the same pattern we see across the WordPress ecosystem and the reason we have written about when WordPress is the right tool and when it is not: every feature is one plugin away, which makes the surface enormous unless you keep discipline. For a small-business site the same trade-off plays out at every step, as we covered in the small business website guide.
Frequently asked questions
Does disabling XML-RPC affect SEO?
No. XML-RPC is not crawled or used by search engines. Disabling it removes attack surface only.
Will the WordPress mobile app stop working?
The official WordPress and Jetpack apps now authenticate over the REST API using application passwords. As long as your install is on a current version of WordPress and Jetpack, both apps work fine with XML-RPC off.
What about pingbacks and trackbacks?
They go away. In practice this matters to almost nobody. Pingback notifications have been dominated by spam for over a decade. Most active WordPress site admins have already disabled them under Settings → Discussion. Closing XML-RPC enforces that more thoroughly.
What if my host already blocks XML-RPC?
Some managed WordPress hosts (Kinsta, WP Engine, SiteGround on certain plans) block xmlrpc.php at the platform layer. Visit /xmlrpc.php on your site to confirm. If you see a 403 or a host-branded block page, you are done. Adding the PHP filter on top is harmless redundancy.
Can I do this through the WordPress admin without touching code?
Not in core, no. WordPress does not expose an off switch for XML-RPC in the dashboard. Either you add the filter, edit the web server config, or install a plugin whose only job is to flip that filter for you. The one-line code change is by far the smallest, lightest option.
I run a multisite, anything different?
Same fix, applied network-wide. Put the filter in a network-activated mu-plugin (drop it in wp-content/mu-plugins/) and it covers every site in the network without per-site activation.
The bottom line
XML-RPC is a 1998 protocol kept alive in WordPress core for backwards compatibility with software that mostly no longer exists. In 2026, leaving xmlrpc.php public means handing attackers a brute-force amplifier, a username oracle, and a DDoS reflector in the same file. Disabling it costs nothing, breaks almost nothing, and is one of the highest-ROI security changes you can make on a WordPress site.
If you want us to harden an existing WordPress site, audit which endpoints are exposed, lock down logins, set up backups and a real staging environment, that is part of how we approach WordPress projects. Get in touch and we will walk you through the current state of your site before anything else.