Every WordPress installation ships with a file called xmlrpc.php in its root directory, enabled by default. I see it abused in server logs constantly.
It is a legacy remote procedure call endpoint, introduced before the REST API existed. Back then, it was the only way for external apps to talk to WordPress. Today the REST API covers all of those use cases with better authentication and rate limiting.
Unless you have a specific reason to keep xmlrpc.php, you should disable it.
Why xmlrpc.php Is a Security Risk
WordPress’s XML-RPC implementation has no rate limiting and no lockout mechanism. Three attack vectors exploit this:
Brute-force amplification: The system.multicall method lets an attacker bundle hundreds of login attempts into a single HTTP request. Security plugins watching /wp-login.php never see them.
The system.multicall method allows multiple calls to be made within a single request. An attacker can use it to attempt hundreds of passwords at once while only generating a single HTTP request in the server logs. – Perishable Press, “Protect Against WordPress Brute Force Amplification Attack”
DDoS amplification: Attackers send forged pingback requests through your site to flood a victim’s server. Thousands of WordPress sites become unwitting traffic sources.
Origin IP disclosure: Pingback requests are made server-side, bypassing CDNs like Cloudflare. This exposes your real server IP even when security headers and proxy protection are in place.
How to Disable xmlrpc.php
Pick the method that matches your hosting setup.
Option A: Block at the Server Level (Recommended)
Requests never reach PHP, so this is the most efficient approach.
Apache – add to .htaccess:
<Files "xmlrpc.php">
Require all denied
</Files>Nginx – add to your server block, then reload:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Option B: Disable via a Must-Use Plugin
If you cannot edit server config (common on shared hosting), create wp-content/mu-plugins/disable-xmlrpc.php:
<?php
add_filter( 'xmlrpc_methods', '__return_empty_array' );
remove_action( 'wp_head', 'rsd_link' );The xmlrpc_enabled filter you see in many tutorials only blocks authenticated methods. Pingbacks and system.listMethods still work, so use xmlrpc_methods instead.
Option C: Block with a Security Plugin
Wordfence, Sucuri, and iThemes Security all include an XML-RPC toggle. Check your plugin’s firewall settings before adding manual rules on top.
| Method | Level | Stops PHP | Best For |
|---|---|---|---|
| .htaccess / Nginx rule | Server | Yes | VPS, dedicated, managed hosting |
MU-plugin (xmlrpc_methods) | PHP | No | Shared hosting |
| Security plugin toggle | PHP | No | Sites already running a security plugin |
What Breaks When You Disable It
For most sites, nothing. The main exceptions:
- Jetpack relies on XML-RPC to connect to WordPress.com. If you use Jetpack, keep XML-RPC enabled or whitelist Jetpack’s IP ranges. (Jetpack uses token-based auth, so it is safer than standard XML-RPC.)
- WordPress mobile app – older connection methods use XML-RPC, but newer app versions default to the REST API.
- Pingbacks/trackbacks stop working, which is a benefit since they are almost exclusively abused for spam.
How to Verify It Worked
Run a quick check from your terminal:
curl -s -o /dev/null -w "%{http_code}" https://yourdomain.com/xmlrpc.phpA 403 response means the server block is working. If you used the PHP filter, send a test call instead:
curl -X POST https://yourdomain.com/xmlrpc.php
-H "Content-Type: text/xml"
-d '<?xml version="1.0"?><methodCall><methodName>system.listMethods</methodName></methodCall>'An empty methods array in the response confirms xmlrpc_methods is active.
FAQs
Common questions about disabling XML-RPC on WordPress:
xmlrpc.php is still enabled by default on every new installation. WordPress core has not removed or disabled it, even though the REST API has replaced its functionality since WordPress 4.7.xmlrpc_enabled filter only disables methods that require authentication, like publishing posts or uploading media. Unauthenticated methods such as pingback.ping and system.listMethods remain active. The xmlrpc_methods filter, when set to return an empty array, disables all methods including unauthenticated ones.xmlrpc.php entirely at the server level. Jetpack uses XML-RPC to communicate with WordPress.com. However, Jetpack's implementation uses token-based authentication rather than plain credentials, making it safer than standard XML-RPC. If you run Jetpack, either keep XML-RPC enabled or whitelist Jetpack's IP ranges in your server configuration.xmlrpc.php closes the brute-force amplification vector, but attackers can still target /wp-login.php and the REST API authentication endpoints. Combine disabling XML-RPC with Two-Factor Authentication, login rate limiting, and strong passwords for full protection.xmlrpc.php is not recommended because WordPress core updates will restore it. Instead, block access at the server level or disable the methods via a PHP filter. These approaches survive core updates and do not modify WordPress core files./xmlrpc.php. On Apache, run grep xmlrpc.php /var/log/apache2/access.log | wc -l. On Nginx, check /var/log/nginx/access.log. A high number of POST requests, especially from different IPs, is a strong indicator of brute-force or DDoS amplification attempts.Summary
Most WordPress sites have no reason to keep xmlrpc.php active. Block it at the server level if you can, or use the xmlrpc_methods filter if you cannot. Verify with curl and move on.
Want to harden your site further? See the full guide to improving WordPress security.
