Brute Force Attacks on wp-login.php: How They Work and How to Stop Them

Because WordPress powers over 40% of all websites, and because its login endpoint sits at the same predictable URL on almost every install, wp-login.php receives automated login attempts on nearly every publicly reachable site — often within hours of the domain first resolving, long before a human ever visits.

What these attacks actually look like

Two distinct patterns show up in real logs. Brute force tries many passwords against one known username (often admin or the site owner’s name, guessed from the About page). Credential stuffing tries a huge list of real username/password pairs leaked from unrelated breaches, betting that some fraction of users reuse passwords across sites. Both are almost always automated and distributed across many IP addresses to avoid simple rate limits.

Why "just install a security plugin" isn’t the full answer

Most login-hardening plugins work by blocking an IP after N failed attempts from that IP. That stops naive brute force but does very little against credential stuffing spread across hundreds of IPs, or against an attacker patient enough to stay under the per-IP threshold.

Defenses that actually reduce risk

• Strong, unique passwords, enforced. The entire threat of credential stuffing depends on password reuse. A password manager and a minimum-strength policy remove most of the risk in one step.
• Two-factor authentication on every account with publish or administrator capability, not just the primary admin.
• Rename or restrict the login URL for lower-traffic sites where the SEO cost of unusual routing doesn’t matter — this stops the vast majority of unsophisticated bots, though a targeted attacker will still find it.
• Rate limiting at the edge (a firewall or reverse proxy, not just a WordPress plugin), since a plugin-level block only kicks in after WordPress has already spent CPU processing the request.
• Monitoring login volume over time, not just blocking individual attempts — a sudden spike of 20+ failed logins in 10 minutes is a meaningfully different signal than the same number spread across a week, and deserves a real-time alert rather than a silent log entry nobody reads.

The real risk isn’t the failed attempts

Thousands of failed logins are just internet background noise and rarely worth losing sleep over on their own. What matters is catching the one attempt that succeeds — a new admin session from an unfamiliar IP, immediately following a failed-login burst, is the actual signal worth an alert.

Real-time login-volume monitoring, with the noise-filtering to distinguish background internet scanning from a genuine attack in progress, is covered on the Security page. Per-site pricing for this kind of monitoring starts at $0 for your first site — see Pricing.