WordPress XML-RPC Exploitation: Why xmlrpc.php Is Still the #1 Brute-Force Attack Vector

Over 43% of the world’s top 10 million websites run on WordPress. While the platform has modernized significantly with the WP REST API, millions of servers still leave a legacy protocol enabled by default: XML-RPC (xmlrpc.php).

Automated cybercrime syndicates and botnets constantly scan IPv4 and IPv6 address spaces for active xmlrpc.php endpoints. In this report, we examine how the exploit works under the hood and provide immediate configurations to harden your server.

1. The Vulnerability: The system.multicall Amplification

In standard wp-login.php brute-force attempts, an attacker sends an HTTP POST request for every single password guess. Security plugins and Cloudflare rate limiters easily detect and block this pattern because it triggers hundreds of 401 or 302 responses within seconds.

However, XML-RPC features a native method named system.multicall:

<?xml version="1.0"?>
<methodCall>
  <methodName>system.multicall</methodName>
  <params>
    <param>
      <value>
        <array>
          <data>
            <value>
              <struct>
                <member><name>methodName</name><value><string>wp.getUsersBlogs</string></value></member>
                <member><name>params</name><value><array><data>
                  <value><string>admin</string></value>
                  <value><string>Password123</string></value>
                </data></array></value></member>
              </struct>
            </value>
            <!-- Thousands of additional credential guesses bundled into one request -->
          </data>
        </array>
      </value>
    </param>
  </params>
</methodCall>

Why This Is Lethal:

1. 1.Single Request Bypass: A single HTTP request can bundle 5,000 distinct password guesses.
2. 2.Bypasses Basic WAF Rate Limits: To the server and web application firewall, it appears as a single incoming request, evading basic request-per-minute thresholds.
3. 3.Severe CPU Exhaustion: Processing thousands of cryptographic wp_hash_password bcrypt/MD5 verifications inside a single PHP process causes CPU utilization to spike to 100%, causing a denial of service (DoS) for real visitors.

2. Immediate Remediation Recipes

Unless you are utilizing legacy mobile publishing tools or the Jetpack plugin with external XML-RPC dependencies, xmlrpc.php should be completely disabled.

For Apache / LiteSpeed (.htaccess)

# Block WordPress XML-RPC access completely
<Files xmlrpc.php>
    Order Allow,Deny
    Deny from all
</Files>

Alternatively, if using Apache 2.4+:

<Files "xmlrpc.php">
    Require all denied
</Files>

For Nginx Server Blocks

# Block XML-RPC requests directly at the edge
location = /xmlrpc.php {
    deny all;
    access_log off;
    log_not_found off;
    return 403;
}

For Cloudflare WAF Custom Rule

3. How to Verify Your Fix

Test your endpoint directly from your terminal using curl:

curl -I -X POST https://yourdomain.com/xmlrpc.php

If hardened properly, the server will immediately return an HTTP/1.1 403 Forbidden response without invoking the PHP interpreter.

4. Run an Instant Security Audit

Is your server actively exposing xmlrpc.php? Run your website through the AELIONIX security diagnostic to detect exposed administrative endpoints, missing security headers, and outdated JavaScript libraries.