Most WordPress sites that get hit through XML-RPC were not ignoring security. They just forgot the endpoint was still there.
That is what makes XML-RPC abuse so persistent. It lives in the category of things people meant to review at some point and never quite came back to. Then months later they are trying to explain why the origin has been handling a steady stream of useless requests to /xmlrpc.php.
The attack is old. The operational pain is still current.
Why XML-RPC still causes real pressure
XML-RPC is one of those WordPress features that survives in production long after many sites have stopped needing it.
If a site genuinely relies on it, fine. Keep it and protect it properly.
What I do not like is leaving it exposed by default just because it has always been there. The list of sites that truly need XML-RPC today is much shorter than people pretend.
Attackers still use it for:
- brute-force attempts
- pingback abuse
- repetitive automated requests
- spreading authentication pressure across a less obvious path than
wp-login.php
The worst part is not always the request volume. In practice, most XML-RPC abuse we see is not a dramatic flood. It is a low-grade background drip that operators ignore until PHP workers start queuing and the site feels vaguely unhealthy.
Why "the site is still up" is the wrong comfort
This is the same mistake teams make with other WordPress abuse paths.
They assume the absence of a visible outage means the issue is minor.
Meanwhile, the site is still paying for:
- PHP execution
- application routing
- plugin-side logic
- database reads
- log noise nobody wants to interpret
That is enough to matter, especially on sites that already have busy login paths, WooCommerce traffic, or other dynamic behavior competing for the same resources.
Disabling it is usually better than filtering it
This is the first serious question to answer.
Do you still need XML-RPC?
If the answer is no, then disabling it is usually the cleanest move. Not because every hostile request disappears forever, but because removing unnecessary surface area is more reliable than endlessly filtering around it.
I have a strong bias here. If a feature is old, publicly reachable, and no longer part of the real workflow, I would rather remove it than decorate it with ten defensive bandages.
If you do need it, the control point matters
If XML-RPC must stay enabled, then the question becomes where the traffic gets evaluated.
If WordPress has to wake up and inspect the request before anything useful happens, the origin is still doing the defensive work too late.
That is why I care more about edge-side handling than clever local plugin rules. The goal is not just to recognize hostile requests. The goal is to stop paying origin cost for them.
This is one reason FirePhage WAF is a more useful control point for this kind of pressure. XML-RPC abuse should be treated as part of the edge traffic problem, not just as another WordPress plugin setting.
What XML-RPC abuse actually looks like in logs
The textbook explanation is easy. The real pattern is messier.
You might see:
- repeated POST requests to
/xmlrpc.php - a mix of countries and weak IP rotation
- long periods of low-volume repetition
- login pressure that does not fully show up on the main login path
That last point matters. Teams sometimes believe they have their authentication surface under control because wp-login.php looks quiet. Then XML-RPC is carrying a chunk of the pressure on the side.
This is why I prefer asking "which authentication paths are taking work?" instead of "is login protected?"
Why rate limiting helps even when it is incomplete
Rate limiting is worth using here.
It is not enough on its own.
Both things can be true.
Rate limiting helps because it raises the cost of repetition and reduces the impact of naive automation. What it will not do is fully solve distributed pressure from many sources. If 80 weak hosts are taking turns, a narrow rule is not going to carry the whole job.
That is not a reason to skip it. It is a reason to treat it honestly.
I would much rather use a partial control with realistic expectations than overpromise what one neat-looking rule can do.
Why WooCommerce operators should care too
On a WooCommerce store, XML-RPC is not just a WordPress legacy detail.
It is one more path that can consume resources while the store is already trying to protect:
- customer login flows
- account sessions
- cart and checkout performance
- product/API behavior
That is why I keep repeating the same principle: the more business-critical the site, the less patient I am with unnecessary public attack surface.
If the store does not need XML-RPC, turn it off.
The better operating habit
Review XML-RPC as part of normal surface-area management, not as a special incident project.
Ask:
- do we still need it
- who depends on it
- what happens if we disable it
- if we keep it, is the traffic controlled before origin
That habit is more useful than rediscovering the endpoint every time the site starts feeling slightly slower under unexplained pressure.
The point that matters
If XML-RPC stays exposed, protect it like a real attack surface. If it is not needed, remove it and stop paying origin cost for traffic that should never have existed.