What matters first: A brute-force or credential-stuffing campaign sends large volumes to wp-login.php, XML-RPC or custom login routes. Even failed attempts consume web and PHP resources.
What this symptom actually tells you
Blocking one IP is rarely enough because attacks are distributed. Request rates, targeted usernames and response cost show where to apply controls.
Capture evidence before changing anything
- Measure request volume, paths, source networks and user agents.
- Separate wp-login.php, xmlrpc.php and normal traffic in logs.
- Check PHP-FPM saturation and database queries during the attack.
- Confirm whether any login succeeded or accounts changed.
Most common causes
- Distributed password attack: Many IPs try common or leaked credentials.
- XML-RPC amplification: system.multicall packs many attempts into fewer requests.
- Bot bypass: Attackers rotate agents, cookies or IPv6 addresses.
- Expensive security handling: Each attempt triggers heavy logging, geolocation or database work.
Safe diagnostic and repair sequence
- Rate-limit or challenge the login path at CDN, proxy or web-server level.
- Disable unused XML-RPC methods or the endpoint when the site does not need it.
- Require strong passwords and MFA for privileged accounts.
- Review successful logins, rotate exposed credentials and invalidate sessions.
How to choose between the likely causes
Do not treat Distributed password attack and XML-RPC amplification as interchangeable. Many IPs try common or leaked credentials. By contrast, system.multicall packs many attempts into fewer requests. Use two checks to separate them: Measure request volume, paths, source networks and user agents; and separate wp-login.php, xmlrpc.php and normal traffic in logs. Those observations usually show whether the next safe move is to rate-limit or challenge the login path at CDN, proxy or web-server level or to preserve the current state and widen the investigation.
On a compromised site, containment and cleanup are separate decisions. Preserve the suspicious artefact and access logs before removing persistence, then rotate credentials only after the active path has been closed. Record the exact timestamp, affected URL or transaction, last known good state and every change made during diagnosis. That handover is often what separates a repeatable repair from a temporary disappearance of the symptom.
What not to do
Do not hide the login URL as the only defence. Bots can discover it, and legitimate integrations may break without reducing credential risk.
How to verify the repair
- CPU and PHP worker use remain stable under attack traffic.
- Legitimate administrators can authenticate reliably.
- No unauthorised successful login, role change or new session remains.
A visible symptom disappearing is not enough. Close the incident only when the original failing action, the surrounding business journey and the relevant logs all agree that the fault is gone.
WP REPAIR INCIDENT STANDARD
Reconstruct the incident before fixing it
Blocking one IP is rarely enough because attacks are distributed. Request rates, targeted usernames and response cost show where to apply controls.
- 1
Measure request volume, paths, source networks and user agents.
- 2
Separate wp-login.php, xmlrpc.php and normal traffic in logs.
- 3
Check PHP-FPM saturation and database queries during the attack.
- 4
Confirm whether any login succeeded or accounts changed.
What must be verified
- CPU and PHP worker use remain stable under attack traffic.
- Legitimate administrators can authenticate reliably.
- No unauthorised successful login, role change or new session remains.
Official technical sources
This guide explains the diagnosis. If the site is affected now, the intervention should preserve a rollback path and verify the real business journey.
See the emergency repair service →ABOUT THIS SYMPTOM
Frequently asked questions about this guide.
Will blocking the IP that's hammering my login page stop the CPU spike?+
Usually not for long, because brute-force and credential-stuffing campaigns are typically distributed across many IPs rather than coming from a single source. Rate-limiting or challenging the login path at the CDN, proxy or web-server level addresses the pattern instead of chasing individual addresses.
Does hiding or renaming the wp-login.php URL fix the underlying risk?+
No, this is explicitly flagged as insufficient. Bots can still discover a relocated login URL, and hiding it can break legitimate integrations without actually reducing the credential risk that caused the attack in the first place.
Can failed login attempts alone cause real performance problems, or only successful breaches?+
Even failed attempts consume real web and PHP resources, and some of the load comes from the site's own defenses: heavy logging, geolocation lookups or database work triggered on every attempt can make each request more expensive than the attack itself intends.
How is XML-RPC-based brute forcing different from normal login-page brute forcing?+
XML-RPC amplification uses the system.multicall method to pack many login attempts into a single request, so it can generate far more authentication attempts per request than hitting wp-login.php directly. Disabling unused XML-RPC methods or the endpoint itself is a distinct control from rate-limiting the login page.