Your site is sluggish, your hosting provider is sending warnings about exceeded limits, and the logs show an endless stream of POST requests to xmlrpc.php. If you administer WordPress, this nightmare is probably familiar.

The xmlrpc.php file is a quiet but extremely dangerous element of any WordPress installation. It has lived in your site's root since CMS installation and has remained a favorite entry point for bots and attackers for decades. According to the 2024 Wordfence report, XML-RPC attacks rank among the top five threat vectors for WordPress sites, and nothing has changed in 2026.

Yet most site owners have no idea why this file even exists or how to neutralize it. This guide covers four working methods to block xmlrpc.php, from a quick .htaccess rule to a CDN-level firewall. No fluff, just tested code and explanations of when to use each method.

💡 Quick overview:

• Check whether your xmlrpc.php responds to POST requests (it probably does)
• Choose a blocking method: htaccess, code in functions.php, plugin, or WAF
• Add the blocking rule and verify the endpoint returns 403 Forbidden
• If you use Jetpack, configure targeted firewall protection instead of disabling entirely

What is xmlrpc.php and why is it still in WordPress

XML-RPC (Remote Procedure Call) is a protocol that allows external applications to communicate with WordPress. It was added to the core back in version 1.5 and served for decades as the only API for remote publishing: WordPress mobile apps, desktop clients like Windows Live Writer, and third-party services all relied on it.

With the release of WordPress REST API in version 4.7 (2016), the need for XML-RPC largely disappeared. The modern REST API covers everything XML-RPC used to do, and does it more securely, faster, and with proper authentication via nonce or OAuth.

But the xmlrpc.php file still sits in the root of every WordPress installation. Remote publishing through it is disabled by default, yet the endpoint accepts requests. Just open yoursite.com/xmlrpc.php in a browser to see: "XML-RPC server accepts POST requests only". This means the endpoint is alive and ready for attack.

Why xmlrpc.php is dangerous: main attack vectors

Attackers use xmlrpc.php for two main types of attacks, and both can take down your site.

Brute force via system.multicall. The system.multicall method lets you pack hundreds of authentication attempts into ONE HTTP request. Instead of testing passwords one at a time (as through wp-login.php), a bot sends an array of logins and passwords all at once. Standard login limiter plugins do not detect such requests, to them it looks like "one attempt". Result: attackers cycle through thousands of combinations in seconds without triggering blocks.

Pingback DDoS. The pingback function allows another site to notify your WordPress about a link to it. An attacker sends a forged pingback request, substituting the victim's IP address as the "source". Your server dutifully goes to verify the link and attacks an unsuspecting target host. Scale this across thousands of compromised WordPress installations, and you get a distributed DDoS attack where your site serves as cannon fodder.

Hosting providers track outgoing traffic of this kind and may freeze your account for "participating in DDoS". Meanwhile, your server wastes CPU, memory, and bandwidth servicing junk requests.

Check: does your xmlrpc.php respond

Before blocking, make sure the endpoint is actually open. Open this in your browser:

1
https://yoursite.com/xmlrpc.php

If you see the string "XML-RPC server accepts POST requests only", the endpoint is alive, and attackers can send requests to it. If you get 403 Forbidden or 404, protection is already working.

Second method: send a test POST request via terminal:

1
curl -X POST https://yoursite.com/xmlrpc.php -d '<methodCall><methodName>demo.sayHello</methodName></methodCall>'

A response with 200 OK and an XML structure confirms: XML-RPC accepts requests and is ready for exploitation.

Method 1: quick block via.htaccess

The simplest and most effective method is to block access to the file at the web server level. The request is rejected before it reaches WordPress, which saves server resources and works even if the site is under load.

Add this to your root .htaccess (the one next to wp-config.php):

1
Block xmlrpc.php — protection from brute force and DDoS
2
<Files "xmlrpc.php">
3
    Require all denied
4
</Files>

The Require all denied directive is Apache 2.4+ syntax, current for all modern hosting providers. After saving, open xmlrpc.php in your browser; you should get 403 Forbidden.

If your server runs nginx, add the rule to the virtual host config:

1
location = /xmlrpc.php {
2
    deny all;
3
    return 403;
4
}

After changing the nginx config, remember to reload the server: sudo nginx -s reload.

This method works if you DEFINITELY do not need XML-RPC, not for Jetpack, not for WordPress mobile apps, not for WooCommerce integrations.

Method 2: disabling via functions.php (programmatic method)

If you prefer solving the problem at the code level rather than server configs, here are two tested snippets for your active theme's functions.php or Code Snippets.

Complete XML-RPC disable (WP 3.5+):

1
// Disable XML-RPC completely
2
add_filter('xmlrpc_enabled', '__return_false');

One line, and WordPress stops processing any XML-RPC requests. When attempting to access xmlrpc.php, the client receives an error response; the file itself remains on the server but is functionally dead.

Cleaning wp_head headers from RSD and WLW links:

Even after disabling XML-RPC WordPress continues inserting two lines into <head> that reveal information about your site:

1
// Remove RSD and WLW Manifest links from headers
2
function sd_remove_xmlrpc_headers() {
3
    remove_action('wp_head', 'rsd_link');
4
    remove_action('wp_head', 'wlwmanifest_link');
5
}
6
add_action('init', 'sd_remove_xmlrpc_headers');

The rsd_link and wlwmanifest_link hooks add <link rel="EditURI"> and <link rel="wlwmanifest"> tags to <head>; these exist exclusively for XML-RPC clients and serve no practical purpose in 2026. Remove them.

⚠️ Important: edits to the theme's functions.php will be lost on update. Use a child theme or the Code Snippets plugin for permanent custom code storage.

Method 3: security plugins

If you do not want to touch code, install a plugin. Three tested options:

• Wordfence Security. The most popular WordPress firewall. Besides blocking XML-RPC, it provides a malware scanner, login protection, and traffic monitoring. In Wordfence settings → Login Security → check "Disable XML-RPC authentication".

• Disable XML-RPC-API. A lightweight plugin that does exactly one thing: hooks the xmlrpc_enabled filter and disables the endpoint. No additional settings; activate and forget.

• iThemes Security (Solid Security). A comprehensive plugin with a WordPress Tweaks module where XML-RPC is disabled with a single checkbox. It also closes other vectors: table prefix changes, disabling the file editor from admin, brute force protection.

After activating any of these plugins, always verify that xmlrpc.php returns an error, not a greeting.

Method 4: firewall-level block (Cloudflare / Sucuri)

The most powerful level of protection is a web firewall that discards malicious requests before they even reach your hosting.

Cloudflare** WAF.** Create a custom rule: URI Path field contains xmlrpc.php → action Block. Requests are filtered at the Cloudflare network level (over 330 points of presence worldwide); your server never sees them. The Free plan includes 5 custom rules, which is enough. Bonus: Cloudflare shows blocked request statistics, and you can see the attack scale with your own eyes.

Sucuri Website Firewall. Similar approach: a WAF rule on URI /xmlrpc.php. Sucuri also offers file integrity monitoring and automatic malware cleanup.

A firewall rule works well combined with .htaccess or programmatic disabling: the firewall cuts off mass junk, while the local block serves as a fallback in case traffic somehow bypasses the WAF.

What to do if you use Jetpack

Jetpack from Automattic uses XML-RPC to link your site with WordPress.com servers. If you completely disable xmlrpc.php, Jetpack stops working: stats, subscriptions, image CDN, the Related Posts module, and Jetpack brute force protection all break at once.

The solution: do not kill XML-RPC entirely, but selectively allow requests from Jetpack servers:

• Leave xmlrpc.php accessible (do NOT block via .htaccess and do NOT hook the xmlrpc_enabled filter).

• Configure Cloudflare WAF like this: allow requests to xmlrpc.php ONLY from Automattic IP ranges (the list is updated in Jetpack documentation), block the rest.

• At minimum, remove the RSD and WLW headers using the snippet from method 2, so you do not expose the endpoint in <head> unnecessarily.

• Install Wordfence and enable brute force protection specifically for xmlrpc.php; it does not block legitimate Jetpack requests but cuts password guessing attempts.

⁉️🤔 Frequently asked questions

Can I just delete the xmlrpc.php file from the server?

You can, but this is bad practice. On the next WordPress update, the file will be restored, and you are vulnerable again. It is better to block access via .htaccess or disable functionality with a filter in code: the effect is the same, but core updates will not break your protection. If you did delete the file, be sure to remove rsd_link from wp_head, otherwise visitors will get a 404 when following the EditURI link.

Will disabling XML-RPC break WooCommerce?

No. WooCommerce has fully transitioned to WordPress REST API and does not depend on XML-RPC. Your store will continue working without changes. The only exception is if you use an ancient custom solution tied to XML-RPC, but practically none of those remain.

What if my hosting provider already blocks xmlrpc.php?

If the provider has already disabled XML-RPC at the server level, you do not need to do anything; the endpoint is inaccessible. Check: open xmlrpc.php; if you see 403, protection is working. The only thing worth adding is removing RSD and WLW headers via functions.php, because the provider does not touch those.

Do I need to disable XML-RPC if I'm on managed WordPress hosting?

Most managed hosts (Kinsta, WP Engine, SiteGround) block or strictly limit xmlrpc.php at the platform level. Check whether the endpoint is open via browser. If blocked, no additional action is required. If open, add the .htaccess rule: managed hosts do not overwrite it.

How do I know if my site is being attacked through xmlrpc.php right now?

Three signs: a sharp spike in server load with unchanged traffic, hundreds of identical POST requests to xmlrpc.php in access logs, and memory/CPU limit errors from your hosting provider. Enable monitoring (Wordfence → Live Traffic or Cloudflare → Security Events); you will see the source and scale of the attack in real time.

Is it worth disabling xmlrpc.php in 2026

Short answer: yes, if you do not use Jetpack and do not publish posts through the WordPress mobile app.

XML-RPC is a legacy from the WordPress 1.5 era. REST API has long taken its place, and xmlrpc.php itself has become an open door for brute force and DDoS attacks. Closing it takes five minutes. Choose the method for your situation:

• Do not want to touch code: install Disable XML-RPC-API, two clicks.
• Have access to server files: add a rule to .htaccess, the server level is more reliable.
• Prefer clean code: apply the xmlrpc_enabled filter and remove headers with two snippets in functions.php.
• Want maximum protection: set up a WAF rule in Cloudflare and combine it with a local block.

After blocking, always verify that xmlrpc.php returns 403 Forbidden, and monitor logs for at least a week; you will be surprised how much junk traffic disappears. Also subscribe to WordPress updates: history shows that old protocols die slowly, and new XML-RPC vulnerabilities may surface even after 2026.