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.
Measure the attack before blocking individual addresses
Blocking one IP is rarely enough because attacks are distributed. Request rates, targeted usernames and response cost show where to apply controls.
Separate login routes and their response cost
- 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.
Distributed password attempts versus XML-RPC amplification
- 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.
Contain the attack at the cheapest safe layer
- 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.
Check whether any authentication actually succeeded
A distributed password campaign produces many login attempts across changing sources; XML-RPC amplification can pack many authentication attempts into fewer requests. Separate wp-login.php, xmlrpc.php and custom login routes in logs before choosing controls. The cheapest effective mitigation is usually at the CDN, proxy or web server, before PHP and the database absorb the full request cost.
If XML-RPC is carrying the bulk of the load, use the method-level XML-RPC containment flow. If any login succeeded or files changed during the campaign, add an integrity check against trusted WordPress core instead of assuming the incident ended when CPU dropped.
Do not rely on hiding the login URL
Do not hide the login URL as the only defence. Bots can discover it, and legitimate integrations may break without reducing credential risk.
Verify capacity and accounts after containment
- 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.
Containment is verified when attack traffic no longer exhausts PHP or the database, legitimate administrators can still sign in reliably, and account, session and integrity checks show no unauthorised access remaining.
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.