XML-RPC Exposure Checker
Last updated:
Check whether xmlrpc.php is exposed on your WordPress site. We test if the endpoint responds, lists methods, or allows pingback, then rate the risk and tell you how to lock it down.
Enter a WordPress site URL:
We upgrade & secure WordPress sites, safely.
Backups, PHP upgrades, plugin compatibility checks, rollback safety. You saw the problem above; fixing it is literally our day job.
Stack looks healthy. Want it kept that way?
Our WordPress care plans handle updates, security, backups, and PHP upgrades from $49/mo, so it stays healthy.
Want us to act on this result? Fix these findings →
Prefer the partnership route? Refer clients to us, earn 10% →
How the Checker Works
- Probe xmlrpc.php, a harmless request is sent to the endpoint.
- Read the response, status codes and method lists are parsed.
- Check pingback, the tool notes whether pingback is enabled.
- Rate the risk, you get a clear verdict and a fix.
Why It Matters
- Brute-force amplification, system.multicall lets attackers try many logins at once.
- Pingback abuse, the endpoint can be used for reflected attacks.
- Smaller attack surface, disabling unused endpoints is good hygiene.
- Server load, blocking abuse reduces wasted resources.
xmlrpc.php Risks & Mitigations
xmlrpc.php is enabled by default but most modern sites do not need it, since the REST API now handles publishing and app integrations. These are the specific ways it is abused and how to shut each one down. If you do not use the WordPress mobile app, Jetpack features that require it, or remote publishing, disabling it entirely is the safest choice.
| Risk | Why it matters | Fix |
|---|---|---|
| Brute-force amplification | system.multicall packs hundreds of login guesses into one request, slipping past request-count rate limits. | Disable xmlrpc.php at the server, or block system.multicall and add strict rate limiting. |
| Pingback DDoS | pingback.ping makes your server fetch arbitrary URLs, so many sites can be aimed at one victim as a reflected DDoS. | Remove pingback methods via a filter on xmlrpc_methods, or disable XML-RPC outright. |
| SSRF / port scanning | The same pingback fetch can target internal addresses to map or probe services behind your firewall. | Disable pingback and XML-RPC; do not rely on the endpoint being internal-only. |
| Unneeded attack surface | An enabled endpoint you never use is pure risk with no benefit, and a target for future method vulnerabilities. | If unused: add_filter('xmlrpc_enabled', '__return_false'); plus a server deny rule on the file. |
| Needed but exposed | Some integrations (legacy apps, Jetpack) still require XML-RPC, but full public exposure is unsafe. | Allowlist the integration's IPs, enforce 2FA and rate limits, and remove pingback methods. |
Locking down xmlrpc.php correctly, without breaking an integration you depend on, is part of what our WordPress website maintenance services handle, alongside firewalls, updates, and uptime monitoring.
Next steps
XML-RPC Exposure Checker related tools and articles
Continue with the closest follow-up checks and guides based on this tool's topic, crawl intent, and optimization workflow.
XML-RPC Exposure Checker: FAQ
How does the checker test xmlrpc.php?
What do Exists and Enabled mean?
How is pingback exposure detected?
How should I interpret the XML-RPC risk level?
Is XML-RPC always unnecessary?
What should I do if XML-RPC is enabled?
Why can a firewall or plugin change the result?
Is the URL or XML-RPC response stored?
Free 48-Hour Website Audit
Not sure what to fix first on your own website? We'll review it and tell you, in plain English. Free & non-obligatory.
Want a Hardened, Fast WordPress Site?
We secure, speed up, and maintain WordPress sites so they stay safe and rank well.