288,493 Requests – How I Spotted an XML-RPC Brute Force from a Weird Cache Ratio

The metric that screamed

Today a Cloudflare cache hit ratio on a mostly‑static WordPress site dropped to 0.8% — not a typo, zero point eight. It has been reported that the cause was a single Singapore DigitalOcean IP firing 288,493 POSTs to /xmlrpc.php in 24 hours, all returning 200s. The site stayed up (Cloudflare was doing the heavy lifting) but the origin was chewing CPU on every dynamic request. Why didn’t uptime or basic alerts pick this up? Because the attack looked like legit API traffic, and the real canary was the collapsing cache rate.

The old trick that still works

The vector is ancient but effective: system.multicall. Attackers pack hundreds of credential attempts into a single XML-RPC POST, amplifying one HTTP request into hundreds of login trials. It has been reported that a single system.multicall can test 500 credential pairs in one go, which slips past naive rate‑limiters that count requests instead of auth attempts. Allegedly, that quiet efficiency is why xmlrpc.php remains a favorite in 2026 — efficient, stealthy, and maddeningly persistent.

Fixes and what to do next

The immediate remedy the author used was a Cloudflare WAF rule blocking /xmlrpc.php at the edge plus WP Multitool’s Frontend Optimizer to disable xmlrpc inside WordPress — defense in depth, and both layers are turned on by default in version 1.1.19, it has been reported. Practical takeaway: check your Cloudflare Top Paths (or use the GraphQL analytics query) weekly; if /xmlrpc.php is in the top three with cacheStatus "dynamic" and tens of thousands of hits, you’re being hit. Don’t wait for downtime — watch the cache rate. Curious? That tiny percentage told the whole story.

Sources: marcindudek.dev, Hacker News