How to Prevent XML-RPC and REST API Brute Force Attacks on WordPress

While traditional brute-force attacks target the visual WordPress login page at /wp-login.php, modern botnets rarely waste bandwidth on browser forms. Instead, automated attack tools exploit programmatic APIs: the legacy XML-RPC interface (xmlrpc.php) and the modern WordPress REST API (/wp-json/wp/v2/users).

By leveraging XML-RPC’s system.multicall method, an attacker can submit up to 1,000 username and password guesses in a single HTTP POST request. Standard login rate-limiting plugins (which only track attempts on wp-login.php) remain completely oblivious, while automated botnets brute-force passwords and exhaust database connections on your Linux VPS. In this guide, you will learn how to completely neutralize XML-RPC and secure the REST API without breaking legitimate plugins or mobile workflows.

1. The Mechanics of the XML-RPC Multicall Attack

An attacker initiates a multicall flood by transmitting an XML payload targeting xmlrpc.php:

POST /xmlrpc.php HTTP/1.1
Host: yourdomain.com
Content-Type: application/xml

<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>pass123</string></value></data></array></value></member></struct></value>
            <!-- Hundreds of nested password attempts repeated here -->
          </data>
        </array>
      </value>
    </param>
  </params>
</methodCall>

Because WordPress executes password hashing algorithms (bcrypt/phpass) for each guess sequentially inside PHP, a flood of these requests immediately pushes CPU utilization to 100%, causing the server to become completely unresponsive.

2. Disabling XML-RPC via Nginx Web Server (Zero-CPU Rejection)

The most resilient defense is rejecting XML-RPC requests before they reach the PHP interpreter. Add this explicit block to your Nginx server configuration:

# Drop all requests to xmlrpc.php instantly
location = /xmlrpc.php {
    deny all;
    access_log off;
    log_not_found off;
    return 403;
}

For Jetpack users who require XML-RPC for cloud synchronization, restrict access exclusively to Automattic’s verified IP ranges:

location = /xmlrpc.php {
    # Allow Jetpack cloud IP subnets
    allow 192.0.64.0/18;
    allow 198.181.116.0/22;
    allow 122.248.245.244/32;
    deny all;
    
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;
}

3. Hardening the WordPress REST API

The WordPress REST API exposes public endpoints that automated reconnaissance tools exploit to harvest valid administrative usernames. A simple GET /wp-json/wp/v2/users reveals every registered author slug, providing attackers with the exact usernames needed for brute-force attacks.

Block public user enumeration by adding this filter to an active mu-plugin (/wp-content/mu-plugins/harden-rest.php):

<?php
// Restrict REST API user enumeration to authenticated users only
add_filter('rest_endpoints', function ($endpoints) {
    if (isset($endpoints['/wp/v2/users']) && !current_user_can('list_users')) {
        unset($endpoints['/wp/v2/users']);
    }
    if (isset($endpoints['/wp/v2/users/(?P<id>[\d]+)']) && !current_user_can('list_users')) {
        unset($endpoints['/wp/v2/users/(?P<id>[\d]+)']);
    }
    return $endpoints;
});

4. Rate Limiting wp-login.php with Nginx

To defend standard login pages against distributed credential stuffing, establish dedicated rate limiting zones in Nginx:

# In /etc/nginx/nginx.conf http block
limit_req_zone $binary_remote_addr zone=login_limit:10m rate=1r/s;

# In virtual host server block
location = /wp-login.php {
    limit_req zone=login_limit burst=3 nodelay;
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;
}

If an IP address attempts more than 1 login request per second, Nginx rejects the connection with HTTP 503, preserving server CPU and MariaDB connection pools.

Securing the WordPress REST API: JWT Authentication & Nonce Verification

While locking down xmlrpc.php eliminates legacy brute-force floods, modern headless and decoupled applications still require authenticated REST API endpoints. Enforce these security baselines:

• Requiring JSON Web Token (JWT) Authentication: Restrict private REST API routes to authenticated clients using cryptographically signed JWT tokens. When an external service or mobile app authenticates, the server signs a token using a 256-bit secret defined in wp-config.php:

  define('JWT_AUTH_SECRET_KEY', 'YourCryptographicallyRandomSecretKey2026!');
  define('JWT_AUTH_CORS_ENABLE', true);

  Requests lacking a valid Authorization: Bearer <token> header are rejected before hitting application logic.

• Enforcing WordPress Nonce Verification on Internal AJAX: For internal Gutenberg editor and admin AJAX requests, always verify the X-WP-Nonce header:

  add_action('rest_api_init', function () {
      register_rest_route('custom/v1', '/secure-data', [
          'methods' => 'POST',
          'callback' => 'handle_secure_data',
          'permission_callback' => function () {
              return current_user_can('edit_posts');
          },
      ]);
  });

• Disabling Application Passwords for Untrusted Users: WordPress includes “Application Passwords” for REST authentication. If unused, disable this feature in wp-config.php or via filter:

  add_filter('wp_is_application_passwords_available', '__return_false');

Enterprise Mitigation Checklist: Fail2ban Jail for WordPress REST & XML-RPC

In high-concurrency environments, pair Nginx rate limiting with automated Fail2ban iptables jails to drop botnet IP addresses at the kernel packet filtering layer:

• Configuring Custom Fail2ban Filter: Create a dedicated filter file at /etc/fail2ban/filter.d/nginx-wp-auth.conf to catch repeated XML-RPC and REST authentication failures:

  [Definition]
  failregex = ^<HOST> -.*"(POST /xmlrpc\.php|POST /wp-login\.php|GET /wp-json/wp/v2/users).*HTTP.*" (403|401|503)
  ignoreregex =

• Activating Jail in jail.local: Enable the jail with an escalating ban duration policy:

  [nginx-wp-auth]
  enabled = true
  port = http,https
  filter = nginx-wp-auth
  logpath = /var/log/nginx/access.log
  maxretry = 3
  findtime = 60
  bantime = 86400

• Monitoring Active Kernel Drops: Check current banned botnet subnets via sudo fail2ban-client status nginx-wp-auth to confirm attack mitigation.