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
XML-RPC being reachable is not automatically a breach, but on many sites it is unnecessary exposure that should be reviewed.
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.
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 scanner findings, request a Site Rescue Review to decide whether to restrict it and what to check next.