WordPress brute-force attacks: how they work and how to stop them
When a WordPress site has no obviously vulnerable plugin, a brute-force attempt against the login itself is one of the oldest fallback approaches. It relies on two weaknesses that are easy to overlook: usernames that are trivial to discover, and a login endpoint with no limit on how many times it can be tried.
How usernames get found
WordPress has historically exposed author identity through predictable URLs, such as an author archive reachable by numeric ID. Requesting a short range of IDs and reading the resulting slug or feed link is enough to build a list of valid usernames without ever touching the login form. From there, an attacker has a short list of real accounts to target instead of guessing blindly.
Why the login form is the weak point
A standard login endpoint that returns a different response for a wrong password than for a wrong username, and that has no limit on attempts, lets an attacker test a username/password combination as fast as the server will answer. The classic first pass tries each username against itself or a handful of weak defaults; the second pass runs a password list against a trimmed set of likely accounts. XML-RPC's multicall feature made this worse historically, because it let many credential pairs be tested in a single request, multiplying throughput.
Defences that actually work
No single control closes this gap; a layered set does. Rate limiting and progressive lockouts on the login endpoint remove the ability to guess at scale. Disabling XML-RPC entirely, or at least its multicall method, removes the high-throughput bulk-guessing path. Two-factor authentication makes a correctly guessed password insufficient on its own. Renaming or hiding the default administrator account, and blocking enumeration via the author archive, remove the easy reconnaissance step. A web application firewall in front of wp-login.php adds a further layer that does not depend on WordPress itself being patched quickly.
The takeaway
Brute-forcing is unglamorous precisely because it still works against sites that have patched every known plugin vulnerability. Treating the login endpoint and the author archive as attack surface, not just the plugin list, is what actually closes the gap.
Key takeaways
- WordPress author archives can leak valid usernames without touching the login form.
- An unthrottled login endpoint lets automated tools test credentials as fast as the server responds.
- XML-RPC multicall historically let many credential pairs be tested in a single request.
- Rate limiting, 2FA and disabling XML-RPC together close the gap that patching plugins alone does not.
- Treat the login endpoint and author archive as attack surface, not an afterthought.
This note has been rewritten and checked for this edition; it is not a copy of the original post.