Home / Core Health / Disable xmlrpc.php if you don't need it
Exposed Files · Scan Check Guide

Disable xmlrpc.php if you don't need it

15 min Impact: medium Effort: low ✓ Scan-verified — no manual checkbox

XML-RPC is a WordPress feature (xmlrpc.php) that allows remote posting and pingbacks — it's also one of the most commonly abused endpoints for brute-force login attempts and DDoS amplification attacks, and most sites never actually use its legitimate functionality.

WordPress's xmlrpc.php is a classic, still-actively-exploited target — attackers use it for brute-force login amplification (checking hundreds of password combinations in one request) and as a DDoS pingback relay against other sites.

The full picture

xmlrpc.php represents a legacy feature, historically used for remote publishing and API access on certain content management systems, that has become a genuinely common target for automated attacks specifically because of well-documented vulnerabilities and abuse patterns associated with this specific file across a large volume of sites still running it unnecessarily.

The genuine risk this file presents when unnecessarily enabled includes its historical use in amplification attacks, where attackers leverage this endpoint to conduct brute-force login attempts at unusually high efficiency, and its role in certain denial-of-service attack patterns that specifically exploit this endpoint's particular technical characteristics.

For sites that genuinely don't use the specific remote-publishing or API functionality this file provides — which represents the substantial majority of sites, given how rarely this legacy functionality sees actual legitimate use in current workflows — disabling it entirely removes this specific, well-documented attack surface with no genuine functional loss.

This represents a clear example of the broader security principle that unused functionality should be disabled rather than left enabled by default — every enabled feature, regardless of whether it's actively used, represents potential attack surface, and this specific file's well-documented history of abuse makes it a particularly clear candidate for this general principle's application.

How to fix it

  1. 1
    Confirm you actually need XML-RPC
    If you don't use the WordPress mobile app, remote publishing tools, or Jetpack (which relies on it), you almost certainly don't need it.
  2. 2
    Disable it
    Use a security plugin setting, or add a server-level rule blocking direct access to /xmlrpc.php while leaving the rest of the site untouched.
  3. 3
    If you DO need it, restrict rather than fully block
    Some setups (Jetpack) require it — in that case, restrict access to only the specific IPs or services that need it instead of disabling entirely.

Common mistakes

How you'll know it's done

/xmlrpc.php is disabled or restricted, unless a specific integration you actively use requires it.

H.I.V.E. checks this automatically

Fix it, then re-scan — the check confirms itself. No manual checkbox, the scan is the truth.

Run this check in H.I.V.E. →