XML-RPC WordPress Attacks Explained & How to Disable It

XML-RPC was introduced in WordPress to support remote publishing clients — tools like Windows Live Writer or the old WordPress mobile app. Today it's almost universally unused for its original purpose, but it's still enabled by default on every WordPress site.

Attackers love it.

Why XML-RPC is dangerous

Multicall brute force bypass

The most common XML-RPC attack exploits the system.multicall method, which allows hundreds of function calls in a single HTTP request.

<?xml version="1.0"?>
<methodCall>
  <methodName>system.multicall</methodName>
  <params>
    <param><value><array><data>
      <value><struct>
        <member><name>methodName</name><value>wp.getUsersBlogs</value></member>
        <member><name>params</name><value><array><data>
          <value><string>admin</string></value>
          <value><string>password1</string></value>
        </data></array></value></member>
      </struct></value>
      <!-- repeated 500 more times with different passwords -->
    </data></array></value></param>
  </params>
</methodCall>

A single HTTP request can test 500 passwords. Standard brute force protection that counts requests won't catch this because from the server's perspective it's just one request.

DDoS amplification

Attackers also use compromised WordPress sites as XML-RPC relay nodes. A request to /xmlrpc.php can trigger outbound HTTP requests to third-party pingback targets, amplifying a DDoS attack.

Content injection

If an attacker gains valid credentials via XML-RPC, they can publish, edit, or delete content without ever touching /wp-admin/. This makes hardening your login page even more critical.

Is XML-RPC actually needed?

Very rarely. It's required for:

Jetpack — though Jetpack has moved most functionality to the REST API
WordPress iOS/Android apps (older versions)
ManageWP / MainWP remote management

If you're not using any of these, disable it.

How to disable XML-RPC

Option 1: WO Security Shield (one click)

Go to Hardening → Disable XML-RPC in your WO Security Shield dashboard. It blocks access to xmlrpc.php at the application level and logs any attempts.

Option 2: .htaccess (Apache)

<Files xmlrpc.php>
  Order Deny,Allow
  Deny from all
</Files>

Option 3: Nginx config

location = /xmlrpc.php {
    deny all;
    return 403;
}

Option 4: WordPress filter (allows Jetpack to still work)

add_filter( 'xmlrpc_enabled', '__return_false' );

Note: this disables external calls but leaves xmlrpc.php accessible (still responds with errors). Use the server-level block for full protection.

Monitoring for XML-RPC abuse

Even after disabling XML-RPC, you should monitor for access attempts — they indicate your site is being actively probed.

WO Security Shield logs every request to xmlrpc.php and alerts you if the volume spikes, which can indicate your site is being used as a DDoS relay or is under a targeted attack campaign.

Disabling XML-RPC takes under 5 minutes and closes one of the most exploited attack surfaces on WordPress. Pair this with a properly configured WordPress application firewall for comprehensive protection. Do it now.

Understanding the XML-RPC Attack Surface

XML-RPC (xmlrpc.php) was originally designed to let external applications communicate with WordPress — publishing posts from mobile apps, enabling pingbacks, and supporting the older WordPress desktop client. But this same functionality makes it one of the most exploited files in WordPress.

Types of XML-RPC Attacks

1. Brute-Force Amplification

Unlike the standard wp-login.php login page (which processes one password attempt per request), XML-RPC's system.multicall method allows an attacker to test hundreds of passwords in a single HTTP request:

<!-- A single request testing 500 passwords -->
<methodCall>
  <methodName>system.multicall</methodName>
  <params><param><value><array><data>
    <value><struct>
      <member><name>methodName</name><value>wp.getUsersBlogs</value></member>
      <member><name>params</name><value><array><data>
        <value>admin</value><value>password1</value>
      </data></array></value></member>
    </struct></value>
    <!-- ... repeated 500 times ... -->
  </data></array></value></param></params>
</methodCall>

This bypasses most brute-force protection plugins that count login attempts per request, because technically it's all one request.

2. DDoS Amplification via Pingbacks

The pingback.ping method can be exploited to use your server as a DDoS relay:

Attacker sends a pingback request to your site, pointing to a target URL
Your server makes an HTTP request to the target URL to verify the pingback
Multiply this across thousands of WordPress sites, and the target receives a massive flood of traffic

Your site becomes an unwitting participant in a DDoS attack — and your server resources are consumed in the process.

3. SSRF (Server-Side Request Forgery)

Pingback requests can be crafted to probe your internal network. The attacker sends a pingback URL pointing to internal IP addresses (http://192.168.1.1, http://10.0.0.1), and your server's response reveals information about your internal infrastructure.

Three Ways to Disable XML-RPC

Method 1: .htaccess (Apache) — Recommended

# Block all access to xmlrpc.php
<Files xmlrpc.php>
  Order Deny,Allow
  Deny from all
  # Optionally allow specific IPs:
  # Allow from 203.0.113.50
</Files>

Method 2: Nginx Configuration

# Block xmlrpc.php
location = /xmlrpc.php {
    deny all;
    return 403;
}

Method 3: WordPress Filter (if you can't edit server config)

// Add to functions.php or a custom plugin
add_filter('xmlrpc_enabled', '__return_false');

// Also disable the X-Pingback header
add_filter('wp_headers', function($headers) {
    unset($headers['X-Pingback']);
    return $headers;
});

Method 1 or 2 is preferred because they block the request at the web server level — PHP never even executes. Method 3 still loads WordPress for every request, consuming server resources.

Do I Still Need XML-RPC?

In 2026, almost certainly not. The WordPress REST API (introduced in WordPress 4.7) handles everything XML-RPC used to do — and does it more securely. The only exceptions:

Jetpack — some older Jetpack features still use XML-RPC. Check if you can switch to the REST API connection
Legacy mobile apps — the current WordPress mobile app uses the REST API, but very old versions may need XML-RPC
Custom integrations — if a third-party service specifically requires XML-RPC (unlikely in 2026)

If none of these apply, disable it completely.

XML-RPC Attacks on WordPress: What They Are and How to Stop Them