What matters first: xmlrpc.php supports remote publishing, mobile apps, Jetpack-style services and pingbacks. Attackers target methods that multiply authentication attempts or make outbound requests.
What this symptom actually tells you
A blanket block is safe only when nothing depends on the endpoint. Access logs and method-level inspection show the operational impact.
Capture evidence before changing anything
- Measure XML-RPC request rate, source networks and response time.
- Inspect request bodies or application logs for abused method names where legally appropriate.
- Inventory mobile apps, Jetpack, remote publishing and integrations.
- Check for successful authentication and outbound pingback effects.
Most common causes
- system.multicall abuse: One request contains many login attempts.
- pingback.ping abuse: The site is used to send requests to third parties.
- Credential stuffing: Attackers test leaked usernames and passwords.
- Unbounded processing: Security or logging plugins make each XML-RPC request expensive.
Safe diagnostic and repair sequence
- Block or rate-limit only the unused or abused methods when integrations remain necessary.
- Disable the endpoint at the edge when the site has no XML-RPC dependency.
- Add MFA and rotate credentials if any authentication succeeded.
- Monitor PHP, outbound traffic and logs after the restriction.
How to choose between the likely causes
Do not treat system.multicall abuse and pingback.ping abuse as interchangeable. One request contains many login attempts. By contrast, the site is used to send requests to third parties. Use two checks to separate them: Measure XML-RPC request rate, source networks and response time; and inspect request bodies or application logs for abused method names where legally appropriate. Those observations usually show whether the next safe move is to block or rate-limit only the unused or abused methods when integrations remain necessary or to preserve the current state and widen the investigation.
On a compromised site, containment and cleanup are separate decisions. Preserve the suspicious artefact and access logs before removing persistence, then rotate credentials only after the active path has been closed. Record the exact timestamp, affected URL or transaction, last known good state and every change made during diagnosis. That handover is often what separates a repeatable repair from a temporary disappearance of the symptom.
What not to do
Do not disable XML-RPC without checking Jetpack, mobile apps or external publishing. An emergency block should be documented and tested.
How to verify the repair
- Attack traffic no longer exhausts PHP or triggers outbound abuse.
- Required integrations still work or have an approved replacement.
- No compromised account or unauthorised session remains.
A visible symptom disappearing is not enough. Close the incident only when the original failing action, the surrounding business journey and the relevant logs all agree that the fault is gone.
WP REPAIR INCIDENT STANDARD
How to narrow the fault without guessing
A blanket block is safe only when nothing depends on the endpoint. Access logs and method-level inspection show the operational impact.
Measure XML-RPC request rate, source networks and response time.
Inspect request bodies or application logs for abused method names where legally appropriate.
Inventory mobile apps, Jetpack, remote publishing and integrations.
Check for successful authentication and outbound pingback effects.
What must be verified
- Attack traffic no longer exhausts PHP or triggers outbound abuse.
- Required integrations still work or have an approved replacement.
- No compromised account or unauthorised session remains.
Official technical sources
This guide explains the diagnosis. If the site is affected now, the intervention should preserve a rollback path and verify the real business journey.
See the emergency repair service →ABOUT THIS SYMPTOM
Frequently asked questions about this guide.
Is it always safe to just block xmlrpc.php entirely?+
Only when nothing depends on the endpoint. Jetpack-style services, mobile apps and remote publishing tools commonly rely on XML-RPC, so an emergency block should be documented, tested and based on an actual inventory of integrations rather than assumed to be harmless.
What's the difference between system.multicall abuse and pingback.ping abuse?+
system.multicall abuse packs many login attempts into a single request to accelerate credential guessing, while pingback.ping abuse uses your site to send outbound requests to third parties, effectively turning it into an attack tool against other targets. Distinguishing them requires inspecting request bodies or logs for the specific abused method name.
If I restrict XML-RPC, do I need to do anything else afterward?+
Yes. If any authentication succeeded during the attack, add MFA and rotate credentials, and continue monitoring PHP load, outbound traffic and logs after the restriction to confirm the abuse has actually stopped rather than just changed shape.
Can XML-RPC abuse affect other websites, not just mine?+
Yes, specifically through pingback.ping abuse, where your site is used to send requests to third parties. Checking for outbound pingback effects is part of the recommended evidence-gathering step, since your server can become an unwitting participant in attacking someone else's site.