Introduction

XML-RPC brute force attacks are noisy, persistent, and easy to misread as ordinary login failures. Attackers often use xmlrpc.php because it can bundle authentication attempts and bypass defenses aimed only at /wp-login.php. The safest recovery approach is to verify whether XML-RPC is actually needed, reduce the exposed attack surface, and keep only the integrations your site still depends on.

Symptoms

  • Logs show repeated requests to xmlrpc.php from many IP addresses
  • Login failures spike even though the standard login page is protected
  • Server load rises during repeated authentication bursts
  • Security tools flag multicall abuse or brute force activity against WordPress
  • The attack intensified after bots discovered the site or an old defense was removed

Common Causes

  • XML-RPC remains publicly enabled even though the site no longer needs it
  • Rate limits and WAF rules protect /wp-login.php but not xmlrpc.php
  • Legacy mobile apps, Jetpack, or remote publishing requirements were never reviewed
  • Weak passwords or reused credentials make brute force attempts more dangerous
  • Hosting or plugin defenses are tuned for single-request logins rather than batched XML-RPC abuse

Step-by-Step Fix

  1. Confirm the abusive traffic is targeting xmlrpc.php and determine whether requests are simple probes or active authentication attempts.
  2. Check whether your site still requires XML-RPC for any legitimate integration such as Jetpack or remote publishing tools.
  3. Review WordPress, WAF, and hosting logs to measure attack volume, source patterns, and whether login attempts are succeeding.
  4. Restrict or disable XML-RPC if it is not needed, rather than leaving the endpoint publicly exposed by default.
  5. If XML-RPC must remain available, apply targeted protections such as rate limits, IP restrictions, or endpoint-specific WAF rules.
  6. Rotate weak or exposed credentials and verify administrator accounts use strong passwords and MFA where available.
  7. Confirm no unauthorized users or suspicious sessions appeared during the attack window.
  8. Retest legitimate integrations after hardening so you do not break business-critical remote publishing or sync workflows.
  9. Keep XML-RPC exposure under periodic review because old integrations are often forgotten long after the site stops needing them.