Every WordPress site on the internet is being probed at its login screen right now — yours included, whether you’ve noticed or not. That constant background knocking is why WordPress brute-force protection matters for even the smallest business site. Brute-force attacks are automated, tireless, and cheap for attackers to run, which makes the login page one of the most attacked surfaces on the web. The good news is that the defenses are well understood and, done right, they shut this down almost completely. Here’s how the attacks work and how to stop them.
What a brute-force attack actually is
A brute-force attack is exactly what it sounds like: software guessing username and password combinations over and over until it finds one that works. There’s no cleverness to it, just volume and patience — an automated script can attempt thousands of combinations, and it never gets tired or discouraged. A related and even more effective variant is credential stuffing, where instead of guessing blindly, the attacker uses real username-and-password pairs leaked in other companies’ data breaches, betting that people reuse passwords across sites. That bet pays off far too often.
Both are among the top ways sites get compromised, sitting right behind vulnerable plugins and themes — the subject of our companion piece on why WordPress sites get hacked. If an attacker guesses or reuses their way into an admin account, they don’t need any software vulnerability at all. They just log in.
The two doors: wp-login.php and XML-RPC
WordPress brute-force attempts overwhelmingly target two entry points, and it helps to know both:
- wp-login.php — the standard login page. Attackers submit login attempt after login attempt against it directly.
- XML-RPC — an older WordPress interface (
xmlrpc.php) that many sites don’t actually use anymore. It’s a favorite for attackers because it can allow many login guesses in a single request, making brute-forcing faster and quieter than hammering the normal login page. It’s also abused to amplify denial-of-service attacks.
If your site doesn’t rely on XML-RPC — most modern sites don’t — blocking or tightly restricting it removes a whole category of automated abuse in one move.
How to defend the login: the layers that work
No single setting stops brute-force attacks; a few simple layers together make them futile. From the front line inward:
1. Rate limiting and lockouts
Limit how many login attempts an IP address can make in a given window, and slow down or block ones that cross the line. This turns “thousands of guesses per minute” into a trickle that will never realistically land, without inconveniencing a legitimate person who fat-fingers their password once or twice.
2. Strong, unique passwords
A long, unique password is mathematically hard to guess and — because it isn’t reused — can’t be found in someone else’s breach. This is the foundation everything else rests on. A weak or reused password undermines every other defense.
3. Two-factor authentication (2FA)
With 2FA on, a correct password alone isn’t enough; the attacker also needs the second factor from your phone or app. For admin and editor accounts especially, this is one of the highest-value protections you can turn on, because it makes a guessed or stolen password nearly worthless on its own.
4. Breached-password defense
This one directly answers credential stuffing. Enormous lists of passwords exposed in past breaches circulate freely, and attackers spray them at logins. Checking credentials against known-breached passwords and refusing them closes that door — a password known to be compromised simply isn’t allowed to protect an account. The tricky part is that a breached-password spray can otherwise look like normal, correct logins, so catching it needs to happen at the credential level.
5. Sensible usernames and lockdown of unused back doors
Avoid predictable usernames like “admin” so attackers have to guess both halves, and disable XML-RPC (an old remote-access feature) and other old back doors you don’t use so there are fewer doors to defend.
Why blocking by your host beats blocking by a plugin
You can implement several of these defenses with a plugin — but there’s a meaningful difference in where the blocking happens. A plugin runs inside WordPress, which means every malicious login attempt still reaches your server, loads PHP (the programming language WordPress runs on), and boots WordPress before the plugin rejects it. Under a heavy attack, that’s a lot of wasted work, and it can slow or destabilize a small site even when the attack never succeeds.
Blocking by your host, out front, stops the attempts earlier — at the firewall, before they consume your site’s resources at all. A layered firewall filters abusive requests, and a shared list of known attackers means a computer already caught guessing passwords on other sites is blocked before it gets a single guess at yours. The attack is turned away at the gate rather than absorbed in the hallway. That’s both stronger protection and lighter on your site, and it’s a recurring theme across our WordPress security checklist: the best place to stop bad traffic is before it arrives.
How we handle it
On our managed plans, login protection runs at the platform level, so you don’t have to assemble it yourself:
- Layered firewall filtering abusive login traffic before it reaches your site.
- A live list of known attackers blocking computers already known for attacking other sites.
- Breached-password login defense that refuses credentials known to be compromised, shutting down credential stuffing.
- Rate limiting so brute-force volume never gets traction.
- Locking down XML-RPC and other old back doors where it isn’t needed.
One honest note on the login experience: good protection is forgiving to real people. A customer or team member mistyping a password shouldn’t get permanently locked out — brute-force campaigns get blocked, but there’s always a path back in for the legitimate owner. The goal is to stop the flood, not to trap the person who owns the site.
The takeaway
Brute-force and credential-stuffing attacks are constant, automated, and aimed at every WordPress site regardless of size — but they’re also very beatable with a few layers: rate limiting, strong unique passwords, 2FA, breached-password defense, and blocking that happens out front rather than inside your site. If you’re already dealing with the aftermath of a successful login attack, how to fix a hacked WordPress site walks you through recovery. And if you’d rather have this handled at the platform level, take a look at our managed WordPress plans — the firewall, live lists of known attackers, and breached-password defense are all included in the flat price, with support any hour when you need it.