To block xmlrpc.php in WordPress, add a rule to your .htaccess file that denies all requests to that file — this is the most effective, immediate approach and requires no plugins.
The xmlrpc.php file is a legacy WordPress interface designed to let external applications (such as old mobile apps and Jetpack) communicate with the site. Today the WordPress REST API handles those needs, and on most sites xmlrpc.php serves only as an entry point for attackers. Here is why it is dangerous and how to close it off.
Why xmlrpc.php Is a Security Risk
Attackers exploit xmlrpc.php in three main ways:
- Amplified brute force: The
system.multicallmethod lets attackers test hundreds of username/password combinations in a single HTTP request, bypassing login attempt limits that only count individual requests. - DDoS amplification: The server responds with payloads far larger than the request, turning it into an amplification relay.
- Internal network scanning via pingbacks: The pingback feature can be used to probe internal services on the server's network.
WAF firewall statistics show that xmlrpc.php receives between 10 % and 30 % of all malicious traffic targeting WordPress installations. For most modern sites, blocking it breaks nothing.
Method 1: Block xmlrpc.php with .htaccess (Apache)
This is the recommended method for Apache servers, which covers the majority of shared hosting and cPanel environments.
Open .htaccess in your WordPress root directory and add these lines above the WordPress block:
# Block access to xmlrpc.php
<Files xmlrpc.php>
Order Deny,Allow
Deny from all
</Files>
Save the file. The server will return a 403 Forbidden response to any request for xmlrpc.php, without executing any PHP logic.
Alternative with mod_rewrite
# Alternative using RewriteRule
RewriteRule ^xmlrpc\.php$ - [F,L]
Both options are equally effective. The <Files> directive is slightly more efficient because it acts at the Apache configuration level, before mod_rewrite processes the request.
Method 2: Block xmlrpc.php in Nginx
If your server runs Nginx, add this block inside the server context for your site:
location = /xmlrpc.php {
deny all;
return 403;
}
Reload the Nginx configuration with sudo nginx -s reload or the equivalent command in your admin panel.
Method 3: Block xmlrpc.php with a WordPress Plugin
If you do not have access to server files or prefer a no-code solution, a plugin works too:
- Disable XML-RPC: A lightweight, single-purpose plugin. Install, activate, and you are done — no extra configuration.
- Wordfence Security: From its dashboard, go to Firewall → Blocking and add a rule for
xmlrpc.php. It also offers country blocking and login attempt limits. - Solid Security (formerly iThemes Security): Includes a "Disable XML-RPC" toggle under the Hardening section.
The drawback of plugin-based blocking is that the rule fires after PHP has loaded all of WordPress — less efficient than server-level blocking.
How to Verify xmlrpc.php Is Blocked
Check the block from a terminal using curl:
curl -s -o /dev/null -w "%{http_code}" https://yourdomain.com/xmlrpc.php
You should get a 403 response. If you get a 200 or an XML response body, the block is not active.
You can also use online tools such as xmlrpc.defense.cc, or simply open the file in your browser — a 403 error confirms it is protected.
What If You Still Need xmlrpc.php?
Cases where xmlrpc.php is still required are increasingly rare:
- Jetpack: Modern versions of Jetpack use the WordPress REST API. Update Jetpack before blocking xmlrpc.
- Legacy desktop apps (e.g., Windows Live Writer): Consider switching to a modern tool that supports the REST API.
- Legacy third-party integrations: Ask your service provider whether a REST API alternative is available.
If you need xmlrpc.php active only for a specific IP address (for example, your app's server IP), use this .htaccess variant:
<Files xmlrpc.php>
Order Deny,Allow
Deny from all
Allow from 203.0.113.10
</Files>
For a complete WordPress security strategy — xmlrpc blocking, header hardening, and plugin auditing — the specialists at elenlace.com are ready to help businesses across Mexico.
Key Takeaways
- xmlrpc.php is an actively exploited attack vector in WordPress used for brute force, DDoS, and internal network scanning.
- The most efficient method is server-level blocking: with
<Files>in Apache or alocationblock in Nginx. - Most modern WordPress sites do not need xmlrpc.php — the REST API covers all its features.
- Verify the block with
curlor your browser: the server must return a 403. - If a service requires xmlrpc.php, restrict access to specific IPs instead of leaving it open to the world.
Blocking xmlrpc.php is one step in a complete WordPress hardening checklist. For a full security review of your site, visit elenlace.com and request an audit.
FAQ
Does blocking xmlrpc.php break WordPress login?
No. The standard WordPress login uses /wp-login.php, not xmlrpc.php. Blocking xmlrpc does not affect dashboard access or any front-end functionality.
Does WordPress 6.x still include xmlrpc.php?
Yes. Even though the REST API replaced its features, the file is still bundled with WordPress for backward compatibility. It will not disappear any time soon, so blocking it manually remains necessary.
Is it enough to disable XML-RPC from the WordPress dashboard?
WordPress has no built-in option to disable xmlrpc.php from the admin panel. Without a plugin, the only way to block it is at the server level (.htaccess or Nginx). Security plugins add that toggle, but with a higher performance cost than server-level blocking.
What is the difference between blocking xmlrpc.php and disabling it with a PHP filter?
The PHP filter (add_filter('xmlrpc_enabled', '__return_false')) disables the functionality, but WordPress still fully loads the file on every request. Server-level blocking (Apache/Nginx) rejects the request before PHP runs at all, which also reduces server load significantly.
Compare providers
Other providers and guides worth comparing:
