Stop WordPress Login Brute-Force Attacks

The fastest fix is to install a login-limiting plugin (like Limit Login Attempts Reloaded) set to lock out an IP after 3-5 failed tries, then add a firewall or .htaccess rule to block the worst offending IPs outright. That stops the automated password-guessing script without you touching a single line of PHP.

This guide is for WordPress site owners who are getting a stream of "failed login" emails, noticed wp-login.php in their server logs getting hammered, or just want to lock the front door before it becomes a problem. By the end you'll know exactly which setting to change, which plugin to install, and how to tell WordPress to stop even answering the door for bots.

How to tell it's actually a brute-force attack

A brute-force attack is simply a script trying username/password combinations over and over, fast, hoping one works. You'll usually spot it through one or more of these signs:

• Repeated "failed login attempt" emails, often several a minute, sometimes for usernames like admin, administrator, or your site name.
• /wp-login.php or /xmlrpc.php showing up dozens or hundreds of times in your server's access log within a short window, often from different IPs.
• The admin login page feels slow to load, or your host's CPU/resource usage graph spikes for no reason you can explain.
• A hosting or security-plugin alert naming "brute force" or "credential stuffing" (the same technique, but using stolen username/password pairs instead of random guesses — OWASP explains the distinction).

If you're not sure whether what you're seeing is normal background noise or a real attack, our free website security check will scan for exposed login endpoints and obvious weaknesses at no cost — no card, no login required.

Why WordPress logins get targeted so often

wp-login.php is at a predictable URL on every default WordPress install, and xmlrpc.php (WordPress's legacy remote-publishing API) can be abused to test hundreds of password guesses in a single HTTP request. Automated bots crawl the web for exactly these two paths and throw lists of common passwords at them — this is listed by OWASP as one of the Automated Threats to Web Applications (Credential Cracking, OAT-007). It's not personal, and it doesn't mean your site was specifically chosen — it's the same script hitting millions of sites, yours included, because the door is in the same place on every WordPress install.

Step 1: Limit login attempts (do this first)

This is the single highest-value fix, and it takes about ten minutes.

1. In your WordPress dashboard, go to Plugins → Add New.
2. Search for and install Limit Login Attempts Reloaded (a free, actively maintained plugin — see its wordpress.org listing). WP Cerber and Wordfence's brute-force protection also work well if you want a plugin that bundles other security features.
3. Activate it, then go to Settings → Limit Login Attempts.
4. Set:

• Allowed retries: 3-4
• Lockout time: 20-60 minutes
• Increase lockout after repeated lockouts: on (this turns short bans into long ones for persistent attackers)

1. Turn on email notifications so you get one summary alert per lockout period, not one per attempt.

This alone won't stop determined attackers, but it kills the noise from unsophisticated bots almost immediately and buys you time to add the stronger layers below.

Step 2: Turn on two-factor authentication

Even a perfectly guessed password is useless to an attacker if they also need a rotating six-digit code from your phone. The Cybersecurity and Infrastructure Security Agency (CISA) recommends multi-factor authentication as one of the highest-impact, lowest-cost defenses against account takeover, and it fully neutralizes brute-force attacks on your admin account specifically.

• Install Wordfence or WP 2FA (both free).
• Require it for every account with an Administrator or Editor role — attackers don't need your account, just any account with publishing or plugin access.

Step 3: Block the attackers, not just the attempts

Limiting attempts slows a script down; blocking its IP address stops it cold. You have three realistic options, in order of effort:

To block a specific IP via .htaccess (place near the top of the file in your site root):

<RequireAll>
    Require all granted
    Require not ip 203.0.113.45
</RequireAll>

Replace 203.0.113.45 with the offending IP from your logs. Repeat the Require not ip line for each address.

For a firewall-level fix (recommended if attacks are ongoing rather than a one-off), turn on a WAF like Cloudflare's free tier or your host's built-in firewall, and add a rate-limiting rule for /wp-login.php and /xmlrpc.php — e.g., "block for 1 hour if more than 5 requests to these paths in 1 minute from the same IP." This stops the request before it ever reaches your server, which also saves you hosting resources.

Step 4: Reduce what attackers can even reach

• Disable XML-RPC if you don't use the WordPress mobile app or Jetpack (which rely on it). Most security plugins have a one-click toggle; otherwise your host or a plugin like Disable XML-RPC can block the endpoint entirely.
• Change the login URL away from the default /wp-login.php using a plugin like WPS Hide Login. This isn't real security on its own (it's "security through obscurity"), but it removes your site from the pool of URLs that generic bots scan automatically.
• Restrict wp-admin by IP if you or your team always log in from the same office or VPN IP — add an IP allowlist at the server or firewall level.

What not to rely on

• A "strong password" alone. It helps, but a brute-force script doesn't get tired — pair it with 2FA and a lockout policy.
• Renaming the login URL as your only defense. It reduces noise, not risk, if XML-RPC and REST API user-enumeration endpoints are still open.
• A CAPTCHA with no rate limiting behind it. Some bots solve CAPTCHAs via cheap human-solving services; it should be one layer, not the whole strategy.

Quick checklist

• [ ] Login-limiting plugin installed, set to lock after 3-4 tries
• [ ] Two-factor authentication required for all Admin/Editor accounts
• [ ] Repeat-offender IPs blocked at .htaccess or firewall level
• [ ] XML-RPC disabled (unless actively used)
• [ ] WAF or host-level rate limiting on /wp-login.php
• [ ] Default admin username removed or renamed if still in use

If you're not sure your fixes actually closed the gap — or you want someone to check the rest of the site while they're in there — a manual security audit catches things automated scanners and default plugin settings miss, like leftover admin accounts or a misconfigured REST API still leaking usernames.

Key takeaways

• Repeated failed-login emails and wp-login.php spikes in your logs mean an automated brute-force script has found your login page — this is extremely common and not a sign you've been personally targeted.
• Install a login-limiting plugin (Limit Login Attempts Reloaded, WP Cerber, or Wordfence) and cap failed attempts at 3-4 before a lockout.
• Two-factor authentication neutralizes brute-force attacks on your account even if a password is guessed correctly.
• Block repeat-offender IPs at the .htaccess or firewall level, and rate-limit /wp-login.php and /xmlrpc.php for lasting protection.
• Disabling XML-RPC and hiding the default login URL cut down the noise but should back up the layers above, not replace them.

None of this is complicated once it's set up, but it's easy to miss one open door — an old plugin, a forgotten admin account, an XML-RPC endpoint nobody remembered was on. If you want a second set of eyes, Circuit is a $49 one-time manual audit where a real security engineer checks your whole site, not just the login page, and hands you a plain-English report of anything else worth fixing.