XML-RPC is a WordPress feature almost nobody uses on purpose any more, and almost every WordPress install still ships it switched on. Crawl Cove's wp-xmlrpc-reachable check exists because that gap between "shipped" and "used" is exactly where attackers look.
What this finding means
This check only runs when Crawl Cove has identified the site as WordPress, and it fires when /xmlrpc.php responds publicly. XML-RPC is WordPress's remote-procedure-call interface: originally built for external blogging clients and pingback notifications, and still enabled by default in a standard install.
A real finding looks like this:
/xmlrpc.php responds, so the XML-RPC interface is publicly reachable.
This is a site-level finding, not a per-page one, since it describes one endpoint that either responds or does not.
Why it matters
An open xmlrpc.php is a standing invitation to two specific kinds of attack. The system.multicall method lets an attacker test hundreds of username/password combinations in a single HTTP request, turning brute-force login attempts from slow and noisy into fast and hard to spot. The pingback.ping method can be abused to make the site send outbound requests on an attacker's behalf, a pattern used in pingback-based DDoS attacks against other sites. Either one can take a site offline, and a site that is down cannot rank.
How to fix it
- Check whether you actually use XML-RPC. The common legitimate uses are: the Jetpack plugin (some features), certain mobile publishing apps, and pingback/trackback notifications between WordPress blogs. If none of these apply, it is safe to disable entirely.
- Disable it in code, since there is no wp-admin setting for this. In a plugin or your theme's
functions.php:
add_filter('xmlrpc_enabled', '__return_false');
- Or block it at the web server, which stops the request before WordPress even loads:
# Apache (.htaccess)
<Files xmlrpc.php>
Order Deny,Allow
Deny from all
</Files>
# Nginx
location = /xmlrpc.php {
deny all;
}
- If you use Jetpack and want to keep only the features you need, consider blocking just the
pingback.pingandpingback.extensions.getPingbacksmethods rather than the whole interface, since those two are the ones most commonly abused. - Re-crawl the site to confirm
/xmlrpc.phpno longer responds publicly.
False positives and edge cases
- This check only ever runs on a site Crawl Cove has identified as WordPress. A non-WordPress site gets zero findings from this check, by design, rather than a guess at what platform it might be running.
- A reachable
xmlrpc.phpis a risk, not proof of a breach. The finding says the door is unlocked, not that anyone has walked through it. - Sites already hardened against brute force (rate limiting, strong unique passwords, two-factor login) carry less real risk from this even while the endpoint stays reachable, though disabling it removes the risk rather than just mitigating it.
Related reading
For the check that flags the WordPress version itself being advertised to anyone who looks, see WordPress Generator Tag Exposing Your Version.
Frequently asked questions
- Will disabling XML-RPC break my site?
- Not for most sites. XML-RPC is only needed by specific integrations: some mobile blogging apps, the Jetpack plugin, and pingback/trackback notifications between blogs. If you don't use any of those, disabling it changes nothing a visitor can see.
- I use Jetpack. Can I still disable this?
- Jetpack specifically depends on XML-RPC for some of its features, so check which Jetpack features you actually use before blocking it site-wide. Blocking only the pingback methods while leaving the rest reachable is the usual compromise.
- Does WordPress have a setting for this?
- No, there is no toggle in wp-admin. It has to be disabled via a filter in code (a plugin or your theme's functions.php) or blocked at the web server level.
- Why is this only a medium-severity finding, not high?
- An open xmlrpc.php is a risk multiplier, not a breach on its own: it makes brute-force and pingback DDoS attacks easier to mount, but it does not by itself grant access to anything. Sites already hardened against brute force (rate limiting, strong passwords, two-factor login) carry less real risk from it, even though the interface is still reachable.