Good to know: SecurynAI's free tier is a fully deterministic security plugin on its own — firewall, scanning, and hardening all work with no setup. Plain-English AI explanations require your own OpenAI or Anthropic API key (typically ~$0.10–$0.30/month); without one, you still get clear fallback explanations, just not full AI narratives.

What xmlrpc.php actually does

xmlrpc.php is a WordPress feature that allows remote applications to interact with your site — historically used by things like the WordPress mobile app, some publishing tools, and pingback/trackback notifications between blogs. It's been part of WordPress core for a long time, and most sites have it enabled by default even though many site owners never use any of the features it supports.

Why it's such a common attack target

Two things make xmlrpc.php especially attractive for automated attacks:

  • It supports a method (system.multicall) that lets an attacker try hundreds of username/password combinations in a single HTTP request, instead of one request per guess. That makes credential-guessing dramatically faster than hitting the normal login page directly.
  • It's rarely monitored as closely as wp-login.php. A lot of basic login-hardening advice focuses on the visible login form and misses this file entirely.

The result is that "brute force" attempts against WordPress sites very often route through this file rather than the login page you'd normally think to watch.

How this actually gets stopped

SecurynAI's firewall applies a dedicated rate limit specifically to xmlrpc.php — capping how many requests a single source can send to it in a short window, by default around 30 per minute. That cap is enforced early, before the request even reaches broader firewall rule matching, and it's applied against the normalized request path specifically so that path tricks (like requesting /./xmlrpc.php instead of /xmlrpc.php) don't slip past the check.

Once a source crosses that limit, further requests to the file are blocked outright for that source.

Should you just disable XML-RPC entirely?

It's a reasonable option if you're certain nothing on your site depends on it — but check first. Some legitimate integrations (certain mobile publishing workflows, some plugin-to-plugin communication, Jetpack in particular) rely on it being available. Disabling it blind can quietly break something you didn't realize used it.

A rate limit is generally the safer default: it neutralizes the specific thing that makes this file dangerous without removing functionality that might still be in use.

What to do if you see repeated warnings

  1. Confirm it's being rate-limited, not just logged. Make sure the requests are actually being capped, not just noted.
  2. Check whether any of the attempts succeeded. A thousand blocked guesses is a non-event; one that got through is not.
  3. Use strong, unique passwords and two-factor authentication on every account, regardless of what's happening at the XML-RPC layer specifically.

Get xmlrpc.php and the rest of your login surface protected automatically.

Install free →