A WordPress brute-force attack sends repeated authentication attempts to wp-login.php, XML-RPC, or related endpoints. Effective defense combines strong credentials and MFA with rate controls, edge filtering, least privilege, and logs that prove what happened.
Identify the Pattern in Logs
Review web access and security-plugin logs for request rate, source networks, usernames, endpoint, user agent, response codes, and timing. One source trying many users is password spraying; many sources targeting one user may be distributed guessing. Confirm server time zone before correlating events.
Protect Accounts First
Use unique passwords from a password manager, MFA for administrators and editors, and separate named accounts. Remove stale administrators and change the public display name so it does not expose the login name. Application integrations should use distinct revocable credentials.
Apply Rate Limits at the Edge
Rate-limit login requests by source and behavior through the CDN, WAF, web server, or security plugin. Start with monitoring or a forgiving threshold to avoid blocking shared offices, mobile networks, and password-manager retries. Escalate repeated behavior to temporary challenges or blocks.
Handle XML-RPC
Disable XML-RPC when unused or restrict its methods, sources, and rate when required. The endpoint can amplify login attempts by allowing multiple method calls. Follow our XML-RPC security guide before applying a blanket rule.
Reduce Attack Surface
Keep WordPress, plugins, themes, PHP, and the host updated. Remove abandoned components. Restrict wp-admin through an identity-aware gateway or VPN for small administrator groups when practical. Changing the login URL can reduce noise but is not a substitute for authentication controls.
Detect a Successful Compromise
Do not stop at failed requests. Review successful administrator logins, new users, role changes, plugin installation, file modifications, scheduled tasks, outbound mail, and unknown sessions. Rotate WordPress, hosting, database, SSH, API, and application credentials according to exposure.
Respond in Order
- Preserve logs and record the time window.
- Challenge or block the narrow attack pattern.
- Force MFA and revoke suspicious sessions.
- Reset affected credentials through a clean device.
- Review files, users, tasks, and outbound activity.
- Patch the entry point and monitor recurrence.
Avoid Harmful Countermeasures
Do not block an entire country when legitimate users are there, permanently ban addresses after one typo, or expose verbose login errors. Do not install multiple overlapping security plugins; conflicting locks and duplicate scans can exhaust hosting resources.
Validate Legitimate Recovery
After enabling login controls, test a normal administrator login, MFA enrollment, lost-factor recovery, password reset email, application integration, and support workflow. Perform the test from a typical office or mobile address as well as the administrator’s usual network.
Record which layer issued a block so support can reverse the correct control. A CDN challenge, host firewall ban, WordPress lockout, and identity-provider denial require different evidence and recovery steps.
Frequently Asked Questions
Does a CAPTCHA stop brute force?
It can reduce automated attempts but should complement MFA, rate limits, and strong credentials.
Should I block the username admin?
Remove or rename predictable accounts as hygiene, but attackers also enumerate real users. Protect every account.
Can failed logins take a site down?
Yes. Uncached authentication requests consume PHP and database resources. Edge rate limits reduce that load before it reaches WordPress.
Final Defense
The durable model is layered: unique accounts, MFA, minimal administrators, controlled login rates, restricted XML-RPC, current software, and alerts that include successful access after failures. Test legitimate login and recovery after every rule change.
