WordPress XML-RPC Security Risks: Why and How to Disable xmlrpc.php in 2026

What Is WordPress XML-RPC?

XML-RPC (Remote Procedure Call) is a protocol that allows external applications to communicate with WordPress over HTTP using XML-formatted requests. The xmlrpc.php file in your WordPress root directory is the endpoint for these requests. It was originally designed to enable mobile apps, desktop blogging clients (like Windows Live Writer), and inter-site communication (pingbacks and trackbacks) to interact with WordPress without accessing the admin dashboard.

Before WordPress introduced the REST API in version 4.7, XML-RPC was the only way for external applications to create posts, upload media, and manage content programmatically. Today, the REST API provides all the same functionality with better authentication, granular permissions, JSON-based data exchange, and modern security practices. XML-RPC remains enabled by default purely for backward compatibility.

The problem is that XML-RPC was designed in an era before modern authentication standards. It accepts username and password in plain text within the XML payload, has no rate limiting, no built-in brute force protection, and supports a method called system.multicall that allows hundreds of authentication attempts in a single HTTP request.

Brute Force Amplification via system.multicall

The system.multicall method is what makes XML-RPC brute force attacks devastating. A single HTTP POST to xmlrpc.php can contain 500+ individual authentication attempts bundled into one request. Login rate limiters that count failed login attempts per request see this as one failed attempt, not 500. IP-based lockouts are bypassed because only one connection is made.

An attacker can test thousands of password/username combinations per minute with minimal network overhead. This amplification factor makes XML-RPC brute force attacks orders of magnitude faster than traditional wp-login.php attacks, and harder to detect because they generate far less log traffic per attempt.

DDoS Pingback Abuse: Your Site as an Attack Weapon

WordPress’s pingback system, which operates through XML-RPC, can be weaponized for DDoS attacks. An attacker sends a pingback request to your xmlrpc.php telling WordPress that a URL on another site has linked to your content. WordPress responds by sending an HTTP request to the “linking” URL to verify the pingback. By faking the linking URL as the victim’s server, the attacker turns your WordPress site into an unwitting participant in a distributed denial-of-service attack.

When coordinated across thousands of WordPress sites with XML-RPC enabled, the combined outbound traffic can overwhelm the victim’s server. Your site becomes a DDoS amplifier, consuming your bandwidth and potentially getting your server IP blacklisted by abuse detection systems. The attacker remains invisible because the traffic originates from legitimate WordPress installations, not their own infrastructure.

Three Methods to Disable XML-RPC Completely

Disabling XML-RPC should happen at multiple layers for defense in depth:

Method 1: WordPress filter (application level) — Adding add_filter('xmlrpc_enabled', '__return_false'); to your theme’s functions.php or a must-use plugin disables XML-RPC within WordPress. The endpoint still responds to requests (returning an error), but no authentication or functionality is processed. This still allows PHP to execute, consuming server resources.

Method 2: Server-level blocking (Apache/.htaccess) — Blocking access to xmlrpc.php at the server level prevents WordPress from even loading. Apache returns a 403 Forbidden before PHP processes anything, saving memory and CPU. This is the most efficient method for Apache servers.

Method 3: Nginx location block — For Nginx servers, a location = /xmlrpc.php { deny all; } directive achieves the same server-level blocking without PHP involvement.

# Apache .htaccess blocking
<Files xmlrpc.php>
    Order Deny,Allow
    Deny from all
</Files>

# WordPress filter (mu-plugin)
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );
add_filter( 'xmlrpc_methods', function() { return []; } );
remove_action( 'wp_head', 'rsd_link' );

REST API: The Secure Modern Alternative

Everything XML-RPC can do, the WordPress REST API does better. The REST API supports OAuth, application passwords, cookie authentication, and JWT tokens. It has built-in nonce verification, capability checks per endpoint, and works with WordPress’s standard authentication infrastructure including login attempt limiting.

The REST API also supports granular permissions — you can grant an application password permission to create posts without giving it access to user management. XML-RPC gives full access to any method the authenticated user has permission for, with no way to restrict specific methods.

However, the REST API itself should be configured carefully. Public endpoints expose data like user lists and content structures. Restricting unnecessary REST API endpoints to authenticated users reduces your attack surface without breaking functionality.

Beyond XML-RPC: Complementary WordPress Security Hardening

Disabling XML-RPC eliminates one attack surface, but a comprehensive WordPress security posture requires multiple layers:

• Hide your WordPress version — Remove version numbers from meta tags, RSS feeds, scripts, and stylesheets. The Hide WP Version Number tool strips version exposure from every public output.
• Obfuscate your login URL — Moving /wp-login.php and /wp-admin to custom URLs eliminates automated brute force traffic. The Login URL Obfuscator generates the rewrite rules.
• Block malicious bots — Automated vulnerability scanners consume server resources and probe for known exploits. The Malicious Bot Blocker stops them at the server level.
• Set security headers — HTTP headers like CSP, HSTS, and X-Frame-Options add browser-level protections. Generate them with the Security Headers Generator.

Frequently Asked Questions