When deploying WordPress in a production environment, every enabled feature should be evaluated for its security and performance implications. By default, WordPress prioritizes backward compatibility, which often results in legacy protocols remaining active on every request.

XML-RPC is a legacy API protocol that allows external applications to interact with a WordPress installation over HTTP. Long before the integration of the modern WordPress REST API, XML-RPC was the standard method for third-party clients to execute remote commands, such as creating posts, managing comments, and uploading media.

The Impact of Disabling XML-RPC: Gains and Losses

XML-RPC is unnecessary for most modern WordPress deployments and represents an avoidable attack surface when unused. However, before disabling it, it is important to understand the trade-offs.

What is lost by disabling XML-RPC:

• The official WordPress mobile application will not be able to connect to the site.
• The Jetpack plugin relies heavily on XML-RPC for many of its core functionalities.
• Legacy remote publishing tools, such as offline blog editors, will cease to function.
• Pingbacks from other WordPress sites will be disabled.

What is gained by disabling XML-RPC:

• Attackers can abuse WordPress XML-RPC for authentication attempts. (Note: WordPress XML-RPC was previously more vulnerable. The core team addressed brute-force amplification concerns in ticket #34336. Before that, the system.multicall method allowed multiple XML-RPC calls within a single HTTP request, which could increase the efficiency of brute-force attempts and reduce the effectiveness of per-request rate limiting.)
• Malicious actors can exploit the pingback feature to use the server as part of a distributed denial-of-service attack against other targets. (A pingback is a WordPress mechanism that allows one website to automatically notify another website when it links to it. In the context of abuse, attackers can forge large numbers of pingback requests that appear to originate from legitimate WordPress sites, forcing the target server to process many HTTP requests. This can be amplified if multiple compromised or spoofed sites are used, turning the pingback mechanism into a vector for distributed DDoS.)
• Automated bots frequently scan and hit the xmlrpc.php endpoint. Blocking these requests early saves PHP worker processes and keeps server logs clean.

Blocking XML-RPC at the Web Server Layer

While application-level PHP filters, such as WordPress plugins or modifying functions.php, successfully disable XML-RPC logic, they still leave the xmlrpc.php file exposed. Processing malicious requests at this layer wastes valuable PHP memory and server bandwidth. It is more effective to drop these requests directly at the web server layer, such as through Nginx or Apache, preventing them from ever reaching or taxing the PHP environment.

Apache

For Apache-based infrastructure, requests can be dropped entirely by adding the following block to the .htaccess file located in the WordPress root directory (the same directory containing wp-config.php):

# Block WordPress xmlrpc.php requests
<Files xmlrpc.php>
  Order Deny,Allow
  Deny from all
</Files>Code language: Apache (apache)

Ensure the code snippet above is placed outside the # BEGIN WordPress and # END WordPress sections to prevent it from being overwritten by WordPress rewrite rules:

Nginx

For infrastructure using Nginx instead of Apache, requests can be dropped entirely by adding this block to the virtual host configuration:

# Deny access to xmlrpc.php
location = /xmlrpc.php {
  deny all;
  access_log off;
  log_not_found off;
}Code language: Nginx (nginx)

Disabling XML-RPC at the Application Level (PHP)

Add the following filter to the theme’s functions.php file to disable XML-RPC at the application layer:

// Disable XML-RPC
add_filter( 'xmlrpc_enabled', '__return_false' );Code language: PHP (php)

This method does not prevent HTTP requests to xmlrpc.php from reaching the server. For environments where XML-RPC is not required, a more robust mitigation is to block access at the web server level.

Upstream Blocking

It is also recommended to block XML-RPC traffic upstream. Dropping requests at the network level ensures malicious traffic never consumes origin bandwidth or compute resources. Many modern deployments already handle this via:

• Cloudflare / CDN Edge Rules: Dropping requests at the CDN or edge WAF layer prevents them from reaching the origin, reducing bandwidth and compute usage. Many modern deployments implement this using Cloudflare or other CDN edge rules, where requests targeting xmlrpc.php can be blocked or challenged. (If you are a Cloudflare user, go to Security -> Security Rules and add
• ModSecurity, an open-source web application firewall, can enforce rules and perform deeper HTTP request inspection than .htaccess. Unlike .htaccess, which primarily handles deterministic path, header, and access rules, ModSecurity can analyze XML-RPC bodies and detect known exploit patterns. This allows it to mitigate entire classes of application-layer attacks.

Cloudflare

If you are a Cloudflare user, implementing this block at the Cloudflare edge via Web Application Firewall (WAF) is optimal because it drops the malicious traffic before it consumes resources on your server.

The Cloudflare edge refers to edge locations, the geographically distributed network of servers that sit between end users and the origin server. These edge nodes terminate incoming HTTP(S) requests, apply security rules such as Web Application Firewall policies, rate limiting, and bot mitigation, and either serve cached content or forward allowed requests to the origin server.

Here are the steps to configure the rule:

• Navigate to your Cloudflare dashboard and select your zone.
• Quick Search (Ctrl-k) for Security > Security Rules in the sidebar. (or Security > WAF > Custom rules depending on the interface version.)
• Click Create rule.
• Set a descriptive rule name, such as “Block XML-RPC“.
• In the expression builder, configure the condition:
  • Field: URI Path
  • Operator: equals
  • Value: /xmlrpc.php
• Under the action section, select Block.
• Click Deploy.

Once active, any HTTP request targeting /xmlrpc.php will be denied at the edge, typically returning an HTTP 403 response before reaching the origin server.

The final rules that will be deployed should look like:

(http.request.uri.path eq "/xmlrpc.php")Code language: plaintext (plaintext)

What is the most robust method to prevent XML-RPC abuse?

Blocking XML-RPC at the Cloudflare edge is the most effective first step because it drops malicious traffic before it can consume your origin server’s bandwidth and resources.

However, adding web server blocks via Nginx or Apache acts as a necessary secondary shield against attackers who might target your origin IP directly, preventing those requests from spawning expensive PHP workers.

Finally, disabling the protocol within the WordPress application itself provides an essential fail-safe to ensure the attack surface remains minimized even if your infrastructure rules are accidentally bypassed or misconfigured during future maintenance.

Conclusion

Prioritizing backward compatibility over security remains a major frustration in the WordPress ecosystem. Leaving a legacy protocol active by default shifts the burden of hardening onto the administrator, forcing everyone to manually secure an endpoint they do not even use.

Applying this configuration is an effective security optimization, provided the environment does not use Jetpack, mobile applications, or legacy remote publishing integrations.