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.
Identify which XML-RPC methods are being abused
A blanket block is safe only when nothing depends on the endpoint. Access logs and method-level inspection show the operational impact.
Inventory legitimate XML-RPC dependencies first
- 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.
system.multicall and pingback.ping create different risks
- 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.
Restrict the smallest necessary surface
- 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.
Tie XML-RPC abuse to account-compromise checks
system.multicall can compress many authentication attempts into one request, while pingback.ping can cause outbound requests to third parties. Request bodies or application logs can distinguish them where inspection is appropriate. The right control depends on whether the site still needs remote publishing, mobile apps or Jetpack-style services.
When the attack is mainly credential pressure, compare it with the broader brute-force containment path. If an authentication succeeded or the incident coincides with changed core files, add a trusted-core integrity check before considering the site clean.
Do not disable required integrations blindly
Do not disable XML-RPC without checking Jetpack, mobile apps or external publishing. An emergency block should be documented and tested.
Verify attack load and integrations after the change
- 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.
The repair is complete when abused XML-RPC traffic no longer consumes damaging resources or triggers outbound requests, required integrations still operate, and no compromised account, session or unexplained file change remains.
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.