HIGH

XML-RPC Enabled

XML-RPC lets attackers run thousands of login attempts at once. Learn how to disable it in two steps.

What is this?

XML-RPC is an old API built into WordPress that let external apps communicate with your site — things like posting from email clients or early mobile apps. WordPress has a modern REST API now, so XML-RPC is largely obsolete. But it's still active by default, and attackers have found creative ways to abuse it. The most common attack uses XML-RPC's "system.multicall" method to bundle up to 200 username/password attempts into a single HTTP request.

Why does it matter?

That bundling trick makes brute-force attacks significantly faster and harder to block with simple rate limiting. A bot can try thousands of passwords per minute via XML-RPC while appearing to make only a few requests. Brute force isn't the only abuse, either: the "pingback.ping" method lets anyone instruct your server to fetch an arbitrary URL, which attackers use to conscript your site into DDoS attacks against other targets — your server burns CPU and bandwidth attacking someone else. If you're not actively using XML-RPC for something specific (most sites aren't), disabling it costs nothing and eliminates both categories of attack. The scan result of "fully enabled" means xmlrpc.php is responding to POST requests without restriction. The full pattern this enables and the four defenses ranked by impact are in the brute-force protection walkthrough.

How to fix it

These steps are written for shared hosting (cPanel, Plesk, or similar). If you have direct server access, see the SSH section below.

Option A (no code): Install the free plugin "Disable XML-RPC" from the WordPress plugin directory. Activate it. Done.

Note: This is the easiest method for non-technical users. One caveat before disabling: modern Jetpack (2024 onward) primarily uses the REST API, but older Jetpack connections and the classic WordPress mobile app still rely on XML-RPC. If either stops working after this change, that's why — re-enable and use a pingback-only block instead.

Option B (via .htaccess): Log in to cPanel → File Manager → public_html → open .htaccess. Add:

<Files xmlrpc.php>
  Require all denied
</Files>

Save.

For developers / SSH access

Edit .htaccess in your site root:

nano /var/www/html/.htaccess

Add the Files block:

<Files xmlrpc.php>
  Require all denied
</Files>

Alternatively, block it at the Nginx level inside your server block:

location = /xmlrpc.php {
  deny all;
}

If you'd rather disable it in PHP (e.g. no .htaccess support), add this to functions.php or a Code Snippets entry:

add_filter('xmlrpc_enabled', '__return_false');

Note: Less complete than the server-level block: this filter disables the authenticated XML-RPC methods (stopping the brute-force vector) but pingback methods still respond. Prefer the .htaccess or Nginx block when you can.

How to verify the fix

Try visiting your-site.com/xmlrpc.php in a browser. A blocked site returns 403 Forbidden or times out. Re-run your scan and check that XML-RPC shows as "pass" or "info" (if the endpoint exists but POST is blocked).

Re-run your scan to confirm this is resolved →

Related issues

Your WordPress login page is publicly accessible. Learn how to protect it from brute-force attacks.

User Enumeration

WordPress is exposing your admin usernames via its REST API. Block it with one code snippet.

← View full security checklist

Prefer to have this handled for you? Get this fixed — Simple ($49) →