What does this usually mean?
XML-RPC can support legitimate integrations, but it is also commonly abused for authentication pressure and amplification-style behavior. The right action depends on whether the site actually needs it.
Guide
WordPress XML-RPC security risk
How to think about XML-RPC exposure on WordPress sites and when it may need review.
Problem
XML-RPC can support legitimate integrations, but it is also commonly abused for authentication pressure and amplification-style behavior. The right action depends on whether the site actually needs it.
Common causes
- XML-RPC remains enabled by default even when no app or integration uses it.
- Security plugins or server rules are not configured to restrict the endpoint.
- Legacy mobile publishing, Jetpack-style integrations, or remote tooling still depend on it.
- Teams disable visible login paths but forget XML-RPC remains reachable.
What to check
- Confirm whether the site has a legitimate XML-RPC dependency.
- Check security plugin, WAF, or server rules for XML-RPC restrictions.
- Review authentication logs for suspicious pressure if available.
- Disable, restrict, or rate-limit XML-RPC where it is not needed.
Next steps
- Run the free diagnostic to collect evidence before changing live orders or payment settings.
- Request a Payment Rescue Review if the evidence is unclear or the risk affects customers, fulfilment, or support.
- Custom setup or fix work is quoted after review, once the likely cause and scope are clear.
Quick answer
What should be checked first?
Confirm whether the site has a legitimate XML-RPC dependency.
Need help checking this on a live store?
If XML-RPC exposure appears alongside other public exposure findings, Security Snapshot can document the no-login public surface and recommended fixes. Credential attacks are not included in the default review.