XML-RPC Exposure Checker

XML-RPC Exposure Checker - Detect WordPress XML-RPC Attack Surface

The XML-RPC Exposure Checker helps you determine whether a site’s WordPress XML-RPC endpoint (usually /xmlrpc.php) is publicly reachable. XML-RPC is a legacy remote procedure interface used by WordPress for features such as remote publishing, some integrations, and historically pingbacks. When exposed unnecessarily, it can expand your attack surface and is commonly associated with brute-force attempts, pingback abuse, and automated probing. This tool performs a safe check of /xmlrpc.php and provides clear guidance on whether you should block, restrict, or leave it enabled based on your needs.

What is XML-RPC in WordPress?

XML-RPC (Extensible Markup Language Remote Procedure Call) is a protocol that allows software to call methods on a remote server using XML over HTTP. WordPress ships with an XML-RPC endpoint at /xmlrpc.php. In the past, it enabled remote publishing workflows, older mobile blogging apps, and features like pingbacks. Today, many modern WordPress setups rely on REST APIs and updated integrations, so XML-RPC is often unnecessary for typical sites.

Why XML-RPC Exposure Matters

When XML-RPC is publicly accessible, attackers may attempt to use it as an entry point. The endpoint is frequently targeted because it is predictable and easy to probe at scale. Common abuse patterns include credential brute-forcing through XML-RPC methods (sometimes bundled into multi-call requests), and pingback-related misuse that can be leveraged for amplification or to trigger traffic to third-party targets. Not every exposed endpoint means you are compromised, but it does mean you should intentionally decide whether you need it and protect it appropriately.

What This Tool Checks

The XML-RPC Exposure Checker performs practical tests against /xmlrpc.php and interprets the response in a way that’s useful for security auditing.

• GET /xmlrpc.php response: Some WordPress installations return a recognizable message indicating the XML-RPC server expects POST requests
• POST /xmlrpc.php response: The tool sends a safe XML-RPC request (system.listMethods) to see whether the endpoint responds with an XML-RPC methodResponse
• Status codes: 200/403/404/401/429 results help determine if the endpoint is open, blocked, removed, authenticated, or rate limited
• Response snippets: You can review short, safe snippets to understand what the server returned

How to Use the XML-RPC Exposure Checker

Enter a domain or URL (example.com or https://example.com). The tool will test the standard WordPress XML-RPC endpoint at /xmlrpc.php using both a GET request and a safe XML-RPC POST. You will receive an exposure result, a score, and recommendations. If the endpoint appears reachable and responds to XML-RPC calls, you should consider whether your site actually uses XML-RPC; if not, blocking it is usually a sensible hardening step.

Interpreting the Results

A result labeled “Exposed” means the endpoint responded in a way that indicates XML-RPC is accessible and active. A “Not exposed (or blocked)” result generally means the endpoint is missing (404), blocked by a WAF/firewall (403), or otherwise protected. Keep in mind that CDNs and security plugins can return custom responses. The tool includes response snippets and HTTP codes to help you understand what happened.

Common Risks Associated with XML-RPC

XML-RPC itself is not automatically dangerous. The risk depends on whether it is exposed unnecessarily and whether login or pingback functionality can be abused. Common risks include brute-force attempts, credential stuffing, and automated scans. Some attackers prefer XML-RPC because they can attempt multiple guesses within fewer requests. If you do not use XML-RPC-based publishing or integrations, disabling or blocking it reduces the attack surface with minimal downside.

When You Might Need XML-RPC

Some environments still rely on XML-RPC, such as certain older publishing workflows, legacy integrations, or specific services that haven’t migrated to modern APIs. If your site uses Jetpack or other plugins, they may use XML-RPC in limited cases (implementation varies by plugin and version). The key is to confirm whether your workflow depends on it before blocking it entirely. If you need it, you can still restrict it safely using IP allowlists, authentication layers, and rate limiting.

Best Practice Recommendations

For most WordPress sites, the strongest baseline recommendation is: if you do not use XML-RPC, block it. Blocking can be done at the web server (Nginx/Apache), at a CDN/WAF, or via a security plugin. If you must keep it enabled, then restrict and monitor it. Enable rate limiting, strong passwords, 2FA, and login attempt limits. Also consider disabling pingbacks if not required, because pingback functionality has historically been abused.

How This Helps Your WordPress Security

Security is often about reducing unnecessary exposure. By identifying whether /xmlrpc.php is reachable, you can proactively close an entry point that many attackers probe. This is especially useful if you manage multiple sites, migrate hosting providers, or recently changed CDN settings. A quick test can reveal whether a previous rule was removed, a plugin stopped blocking XML-RPC, or a new environment accidentally exposed it again.

Troubleshooting and False Positives

Some CDNs and WAFs may intercept requests and return their own responses. In those cases, the tool might show 403 or 401 even if WordPress is present behind the proxy—which is often a good sign. If your site is not WordPress at all, /xmlrpc.php may still exist for other software or return a generic 404 page. Use the HTTP status codes and response snippets as context. The goal is not to guess your CMS, but to identify whether the endpoint behaves like an XML-RPC interface that should be protected.

Practical Next Steps After Checking

If you are exposed and do not need XML-RPC, block it and retest. If you need XML-RPC, restrict access (e.g., by IP), enable rate limiting, and ensure login protection is strong. Maintain an audit checklist: after WordPress core updates, security plugin changes, CDN rule changes, or hosting migrations, re-run this check. Security drift is common, and repeating quick verification checks prevents surprises.

FAQ

Related tools

Pro tip: pair this tool with Security Header Strength Checker and Exposed Admin Path Detector for a faster SEO workflow.

• Security Header Strength Checker — Grade security headers with detailed scoring, letter grades (A+ to F), and actionable recommendations.
• Exposed Admin Path Detector — Detect common admin URLs that may expose login panels or sensitive areas.
• Robots.txt Security Analyzer — Analyze robots.txt to detect exposed admin, login, and sensitive paths.
• Google Malware Checker — Check if site has malware.
• Security Headers Checker — Check if website implements essential security headers like CSP, HSTS, X-Frame-Options.