WordPress XML-RPC: why it's still a security risk in 2026

WordPress XML-RPC enables credential brute-force at scale via multicall and DDoS via pingbacks. How to check if it's enabled and block it properly.

WordPress XML-RPC security risk in 2026 — brute-force and pingback DDoS

xmlrpc.php exists on virtually every WordPress installation. It's a legacy remote publishing interface that predates the REST API. In 2026, almost no legitimate use case requires it — but attackers use it constantly for credential stuffing and amplification attacks.

What XML-RPC does

XML-RPC (/xmlrpc.php) was built to allow remote clients (desktop blogging apps like Windows Live Writer, mobile publishing apps) to post content without a browser. It exposes methods for creating posts, uploading media, managing comments, and — critically — authenticating users.

The system.multicall method is the most dangerous feature: it allows a single HTTP request to bundle hundreds of individual method calls. An attacker can test hundreds of username/password combinations in a single POST request, dramatically reducing the number of HTTP requests needed for a brute-force attack.

Credential brute-force amplification: the multicall attack

A standard brute-force attack against /wp-login.php sends one credential pair per request. Rate limiting, fail2ban, and lockout plugins can detect and block this pattern.

Against xmlrpc.php, using system.multicall, an attacker can send 500 credential pairs in a single POST. Most rate-limiting solutions that count by request count rather than credential count won't block this. A single IP can test thousands of passwords per minute before hitting any threshold.

POST /xmlrpc.php HTTP/1.1
Host: target-site.com
Content-Type: text/xml



  system.multicall
  
    
      methodNamewp.getUsersBlogs
      params
        admin
        password1

DDoS via pingback abuse

XML-RPC includes a pingback mechanism: when your site posts about another site, it can notify that site via an XML-RPC pingback. Attackers abuse this to use WordPress sites as unwitting DDoS amplifiers.

The attack: send a POST to your site's xmlrpc.php with pingback.ping and a target URL as the source. Your WordPress site then makes an outbound HTTP request to the target — acting as an amplifier. Orchestrating this across thousands of WordPress sites with open XML-RPC creates a distributed request flood against the target, with all traffic appearing to originate from legitimate WordPress installations.

How to check if XML-RPC is enabled

curl -s -o /dev/null -w '%{http_code}' https://yourdomain.com/xmlrpc.php

A 200 or 405 response indicates the endpoint is accessible. A proper block returns 403 or 404.

To confirm XML-RPC is actually responding to requests:

curl -s -X POST https://yourdomain.com/xmlrpc.php \
  -H "Content-Type: text/xml" \
  -d 'system.listMethods'

If you receive an XML response listing methods, XML-RPC is fully functional and exposed.

How to disable XML-RPC

Web server block (preferred — nginx)

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

Web server block (Apache)


    Order Allow,Deny
    Deny from all

A web server block prevents PHP from executing at all, eliminating the attack surface completely. Plugins that "disable" XML-RPC work at the PHP/WordPress level — the request still reaches PHP, consuming resources and potentially triggering other code paths.

Why plugin-based disabling is insufficient

Plugins that disable XML-RPC (like Disable XML-RPC or the "Disable XML-RPC" option in Wordfence) hook into the WordPress xmlrpc_enabled filter. This stops WordPress from responding to XML-RPC calls — but only after PHP has loaded, the WordPress bootstrap has run, and all plugins have initialized. For a brute-force flood, this means hundreds of full PHP execution cycles per second, each consuming CPU and memory, before WordPress even has a chance to respond with a rejection.

A web server-level block is a one-line config change that drops the request before PHP ever starts. It is categorically more effective for both security and performance.

Common mistakes

  • Disabling only via plugin — doesn't protect against volumetric attacks exhausting PHP-FPM workers.
  • Blocking /xmlrpc.php but not /wordpress/xmlrpc.php — if WordPress is installed in a subdirectory, adjust the path accordingly.
  • Assuming Cloudflare WAF covers it — Cloudflare's free and Pro tier WAF rules block some XML-RPC abuse patterns, but not all multicall variants. A server-level block is still required.
  • Not testing after blocking — run the curl check after applying the block to confirm it returns 403.

Orb44 checks whether /xmlrpc.php returns a pingable response on every outside scan, flagging sites where it's still accessible. Check your site at orb44.com.

FAQ

Do any legitimate tools still use WordPress XML-RPC?

The WordPress mobile app migrated to the REST API years ago. Jetpack uses XML-RPC for some features but provides an option to allowlist only Jetpack's IPs. Desktop publishing apps like MarsEdit support XML-RPC but also support the REST API. In practice, fewer than 1% of WordPress sites have a legitimate need for XML-RPC that cannot be satisfied by the REST API or IP-restricted allowlisting.

If I block XML-RPC, will it break anything?

Run the system.listMethods test first to see if XML-RPC responds, then check your server access logs for recent /xmlrpc.php requests from non-attack IPs. If you see no legitimate traffic in 30 days, blocking is safe. Jetpack users should consult Jetpack's documentation for its specific IP allowlisting requirements.

Orb44 Journal · all posts