XML-RPC is a legacy WordPress remote procedure call interface originally designed for mobile publishing apps and blog aggregation tools. In the era of the REST API, it is largely obsolete for legitimate use — but it remains active on most WordPress installations and is heavily targeted by automated attacks. A WordPress XML-RPC attack uses this endpoint to amplify brute force attempts, conduct DDoS attacks through the site, or attempt unauthorised admin access at a scale that the standard login page cannot achieve. Understanding the attack mechanics and implementing the correct defences stops it without breaking legitimate functionality that depends on XML-RPC. For the bigger picture, our WordPress Errors Complete Guide pulls everything together.
WordPress XML-RPC Attack — How Attackers Exploit the Endpoint
The WordPress XML-RPC attack exploits two features of XML-RPC that make it uniquely dangerous compared to the standard login endpoint: the multicall method and the lack of login attempt rate limiting on most WordPress configurations.
The multicall attack: XML-RPC supports a system.multicall method that executes multiple API calls in a single HTTP request. An attacker sends a single POST request to /xmlrpc.php containing 500 username/password pairs in a multicall — testing 500 credentials in one HTTP request. The standard WordPress login at /wp-login.php tests one credential per request and can be rate-limited at one-per-request granularity. XML-RPC multicall bypasses this protection entirely — a rate limiter that blocks after 5 failed login attempts sees only one request and does not trigger, while 500 credential pairs are tested. This makes XML-RPC brute force attacks 500× more efficient than login page attacks for the same amount of network traffic.
The DDoS amplification attack: because XML-RPC can authenticate and trigger WordPress actions, attackers compromise poorly-secured WordPress sites and use their XML-RPC endpoints to create distributed botnets. The compromised site receives a POST request with a Pingback API call → WordPress makes an outbound HTTP request to the attacker-specified target → the target receives HTTP traffic appearing to come from the legitimate WordPress site’s IP. This amplification effect allows a botnet of compromised WordPress sites to conduct DDoS attacks against targets while the WordPress site owners’ servers bear the load of processing the inbound XML-RPC requests. A WordPress XML-RPC attack of this type appears in server logs as large numbers of POST requests to /xmlrpc.php from many different source IPs, all containing Pingback method calls. According to Sucuri’s security research, XML-RPC attacks account for a significant proportion of all automated WordPress attacks — blocking the endpoint eliminates this entire attack vector.
Checking Whether XML-RPC Is Being Attacked
Confirm whether the site is under a WordPress XML-RPC attack before blocking via the endpoint. A site that is not being targeted gains nothing from blocking XML-RPC but risks breaking any legitimate integrations that depend on it. A site under active WordPress XML-RPC attack should block the endpoint immediately.
Check server logs for WordPress XML-RPC attack signatures: cPanel → Logs → Raw Access → search for “xmlrpc.php” in the access log. Look for: large numbers of POST requests to /xmlrpc.php from a single or small set of IP addresses (brute force), POST requests from many different IPs with similar user agent strings (botnet), or an unusual spike in /xmlrpc.php traffic coinciding with increased server load. A site receiving hundreds of /xmlrpc.php requests per hour is under active attack. A site with fewer than 10 /xmlrpc.php requests per day is likely just receiving Jetpack connectivity checks or legitimate publishing tool calls.
Test for active WordPress XML-RPC attack exposure: navigate to yoursite.com/xmlrpc.php in a browser. A live XML-RPC endpoint returns “XML-RPC server accepts POST requests only.” A disabled or blocked endpoint returns a 403 Forbidden or 404 Not Found response. Curl test to confirm POST handling: curl -d "" https://yoursite.com/xmlrpc.php — the response “XML-RPC server accepts POST requests only” confirms the endpoint is active. After blocking the WordPress XML-RPC attack vector, the same test should return a 403. Our guide on setting up WordPress two factor authentication covers the login security that complements XML-RPC blocking — 2FA on all admin accounts prevents credential-based attacks even if XML-RPC remains partially active.
Blocking XML-RPC With .htaccess and Nginx
The most efficient defence against a WordPress XML-RPC attack is blocking access to xmlrpc.php entirely at the web server level — before any PHP executes, preventing the attack from consuming PHP or MySQL resources.
Block a WordPress XML-RPC attack via .htaccess (Apache) — add above the # BEGIN WordPress comment:
<Files xmlrpc.php>
Order Deny,Allow
Deny from all
</Files>This returns a 403 Forbidden for all requests to /xmlrpc.php regardless of HTTP method, IP address, or request content. The block is processed by Apache before PHP loads, so it adds zero PHP or database overhead. Test after adding: navigate to yoursite.com/xmlrpc.php → should receive 403 Forbidden. Block a WordPress XML-RPC attack via Nginx — add inside the server block:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}The access_log off and log_not_found off directives prevent the blocked requests from filling the Nginx access log with 403 entries — on a heavily attacked site, this eliminates gigabytes of log data from blocked requests. Verify after adding: nginx -t → service nginx reload → test the xmlrpc.php URL. Cloudflare users can block WordPress XML-RPC attack traffic at the edge network level via a WAF Custom Rule: URI Path equals “/xmlrpc.php” → Action: Block. This blocks the attack before it reaches the origin server — even more efficient than web server-level blocking because Cloudflare’s network absorbs the traffic rather than the hosting server.
Selective XML-RPC — Blocking Only the Dangerous Methods
Some legitimate services depend on XML-RPC — which a WordPress XML-RPC attack block would disable uses it for features including VaultPress backup, downtime monitoring, and Publicize social sharing. Mobile WordPress apps used XML-RPC for posting. WooCommerce legacy integrations may use it. If these legitimate services are active on the site, complete XML-RPC blocking disables them. The selective approach blocks only the WordPress XML-RPC attack vectors while preserving legitimate XML-RPC functionality.
Disable multicall — the most dangerous part of any WordPress XML-RPC attack vector while keeping XML-RPC functional for Jetpack and other legitimate services: add to functions.php: add_filter('xmlrpc_methods', function($methods) { unset($methods['system.multicall']); return $methods; });. This removes the multicall method from the XML-RPC API — individual method calls still work (allowing Jetpack connectivity), but the batched credential testing that makes brute force attacks efficient is eliminated. Add also: add_filter('xmlrpc_enabled', '__return_false'); only if no legitimate XML-RPC service is active. For Jetpack specifically, Jetpack’s newer versions (6.9+) use the REST API rather than XML-RPC for most features — check the Jetpack status in your Jetpack dashboard to confirm which features are REST API-based versus XML-RPC-based before fully blocking the endpoint.
The Disable XML-RPC plugin (free, by John Blackbourn) provides a checkbox toggle for enabling/disabling XML-RPC without editing functions.php or .htaccess — useful for hosting environments where file editing is restricted and a WordPress XML-RPC attack needs to be stopped quickly without server file access. The plugin adds a single filter to disable the XML-RPC endpoint but does not add server-level blocking — it still causes PHP to load on each request (the plugin intercepts the request after WordPress initialises), making it slightly less efficient than the .htaccess block for stopping high-volume attacks. For sites under heavy attack, combine the plugin’s easy toggle with the .htaccess block for server-level efficiency plus plugin-level control management. Reviews from Wordfence’s security research team confirm that XML-RPC blocking eliminates the multicall brute force attack vector and the Pingback DDoS amplification vector simultaneously — two of the most common automated WordPress attack methods in current use.
Monitoring XML-RPC Attack Traffic
After blocking the WordPress XML-RPC attack endpoint, monitoring confirms the blocking is effective and quantifies the attack traffic that was being absorbed by the server before blocking.
Set up a Cloudflare firewall analytics view for XML-RPC: Security → Events → filter by URI Path contains “xmlrpc.php” → the chart shows blocked requests over time. A typical WordPress site that has blocked XML-RPC via Cloudflare sees dozens to hundreds of blocked requests per day — all automated attacks that the server previously processed and now never reach PHP. The Cloudflare analytics also show the geographic distribution of the attack traffic and the attacking IP ranges, useful for identifying whether the attack is from a specific botnet network or distributed globally. On-premise monitoring via server access log analysis tools (GoAccess, AWStats, or cPanel’s Webalizer) provides similar visibility without a CDN — filter the access log for /xmlrpc.php and status code 403 to count blocked requests. The volume drop after implementing WordPress XML-RPC attack blocking is measurable and provides clear confirmation that the blocking is working and that the attack was real rather than a theoretical concern.
Log rotation configuration for XML-RPC attack traffic prevents the server logs from filling with blocked request entries. On servers receiving thousands of blocked XML-RPC requests per day, the access log grows significantly. Configure logrotate to rotate daily and compress with 14-day retention (instead of the default 30 days) for servers under persistent XML-RPC attack — this prevents the disk usage growth that heavy attack logging causes. After implementing WordPress XML-RPC attack blocking at the Nginx level with access_log off; for the xmlrpc.php location, the blocked requests do not appear in logs at all, eliminating the log growth problem entirely on Nginx servers. Our guide on fixing WordPress disk space full covers the log file management context that directly relates to the disk impact of high-volume attack blocking logging on WordPress servers under persistent automated attacks.
Rate limiting the XML-RPC endpoint instead of blocking it entirely is appropriate for sites where Jetpack or other legitimate services cannot function with the endpoint fully blocked, but active WordPress XML-RPC attack traffic is consuming server resources. Cloudflare Rate Limiting (available on Pro plan and above) can be configured to allow a maximum of 10 requests per minute from any single IP to /xmlrpc.php — legitimate Jetpack connectivity checks make only a few requests per minute, while brute force attacks make hundreds or thousands per minute. Any IP exceeding the rate limit receives a 429 Too Many Requests response and is blocked for a configurable duration. This rate limiting eliminates the attack while preserving legitimate XML-RPC functionality at a threshold that is far above legitimate usage patterns but far below the threshold at which brute force attacks become effective. For server-level rate limiting without Cloudflare, Nginx’s limit_req module provides equivalent functionality: limit_req_zone $binary_remote_addr zone=xmlrpc:10m rate=10r/m; location = /xmlrpc.php { limit_req zone=xmlrpc burst=5; }.
IP allowlisting for XML-RPC provides the strictest protection against WordPress XML-RPC attack while maintaining functionality for a known set of trusted IPs. If the only XML-RPC consumer is Jetpack, Automattic publishes the IP ranges Jetpack uses for API connections. Allowlist only these ranges in the .htaccess or Nginx configuration and deny all other IPs: any IP not in the Jetpack range list receives a 403 for /xmlrpc.php requests. This approach provides the security of complete blocking for the entire internet minus the specific IPs that legitimately use XML-RPC on the site. The maintenance burden is keeping the allowed IP list current as Jetpack’s IP ranges change — monitor Automattic’s published IP lists and update the allowlist when ranges change, which typically occurs a few times per year. For sites where the XML-RPC consumer is a known internal tool or a specific partner service, this IP allowlisting approach is the most precise security configuration available for the endpoint.
Reporting active WordPress XML-RPC attack traffic to abuse databases helps protect other WordPress sites in the community — the attacking IP addresses can be submitted to AbuseIPDB (abuseipdb.com), which aggregates reports from across the internet and makes the data available to other site owners and security tools. Wordfence automatically reports attack traffic to its own threat intelligence network, and IP addresses seen attacking multiple Wordfence-protected sites are added to the Wordfence Real-Time IP Blacklist that blocks them network-wide. This shared intelligence model means a WordPress XML-RPC attack campaign that begins targeting a new IP range is quickly identified and blocked across all participating sites, reducing the effective window each new attack campaign has before the attacker IPs are widely blocked.
After stopping a WordPress XML-RPC attack, reviewing the WordPress user accounts for any that may have been successfully compromised during the attack period is an important cleanup step. Check Users → All Users → filter by Administrator → sort by Last Login date. Any administrator account that logged in during the known attack window but whose login was not from a recognised administrator should be investigated — it may represent a successful brute force that preceded the blocking. Change the password immediately for any suspect account, revoke active sessions (Users → Your Profile → Sessions → Log Out Everywhere Else), enable two-factor authentication, and check the site for any changes made by that account during the period. Review the WordPress action log if a logging plugin was active during the attack, comparing the timing of any file changes, plugin activations, or option updates with the attack timeline to identify any damage that occurred before blocking was implemented. Our guide on WordPress Block Editor covers an adjacent issue.
