If you manage a WordPress site, there's a good chance your login page is being tested right now. Not by a person. By a script running through a list of common passwords, trying each one against your login form, hoping to find one that works. That's a WordPress brute force attack, and understanding it is the first step toward real protection.
The scale is staggering. Roughly 65 million brute force attempts are blocked every day across the Wordfence network alone. Globally, an estimated 40 million attempts happen daily across all WordPress installations.
The good news is that brute force attacks are also among the most preventable. Basic protection measures stop the vast majority of them. But "basic" doesn't mean what most guides suggest: installing a login-limiting plugin and calling it done. The real question is where in your infrastructure that protection happens, and that distinction makes all the difference.
This article is part of our broader look at WordPress security threats. Here, we focus specifically on brute force: what it is, why WordPress is vulnerable to it, why your site is being targeted even if you've never done anything controversial, and what layered WordPress brute force protection actually looks like.
What a WordPress Brute Force Attack Actually Is
A brute force attack is an automated attempt to guess login credentials by trying username-password combinations until one works. A bot submits these combinations to your login page, cycling through common passwords, leaked credential databases, and dictionary lists until something hits or the list runs out.
There's nothing sophisticated about it. The attacker doesn't need to know anything about your site. They need a list of common passwords, a script, and your login URL, which WordPress makes predictable by default at /wp-login.php.
Two main variants are worth understanding:
Traditional brute force tries many passwords against a single username. The bot picks "admin" as the username and runs through thousands of password combinations.
Credential stuffing uses username-password pairs leaked from other breaches. Because people reuse passwords across services, an email and password stolen from a data breach elsewhere may work on your WordPress site too. Credential stuffing is now more common than traditional brute force because billions of leaked credentials are freely available.
Both are automated, both are untargeted, and both are running against your site whether you know it or not.
Why Your Site Is a Target for WordPress Login Attacks
The most common misconception we hear is "I'm low threat level, I probably don't need extra security." That's a fundamental misunderstanding of how these attacks work.
"You don't have to be on anyone's threat list. You don't have to be a target. You don't have to be controversial. Your website can fall victim to a security attack even if you've never done anything controversial at all."
Brute force bots scan the internet indiscriminately. They don't evaluate whether your site is "worth" attacking. They find WordPress login pages and start guessing. Your small nonprofit blog gets the same treatment as a Fortune 500 site. Based on our experience managing roughly 200 WordPress sites, about 97% of what we see is automated and 3% is targeted.
On average, a WordPress site faces an attack every 28 minutes. AI-driven botnets have increased brute force attack volume by 45% since early 2025. The largest single campaign Wordfence documented involved 3.5 million attempts, with the average campaign running approximately 56,000.
To put the historical scale in perspective, a December 2017 campaign peaked at 14.1 million attacks per hour, using a botnet of compromised WordPress installations to target sites globally.
The attackers want different things. Some want admin access to inject malware, pharmaceutical spam, or redirect scripts. Others aren't even trying to crack passwords. They're using the sheer volume of WordPress login attempts as a denial-of-service vector, overwhelming your server with authentication requests.
"I haven't seen a brute force attack successfully gain admin access in about 15 years. But I have seen brute force work as a DDoS attack, where the volume alone disrupts the site."
Sucuri's analysis of distributed brute force campaigns backs this up. Approximately 0.5% of attempts received a 200 response (a potential credential match), but the actual success rate dropped below 0.02% after accounting for additional authentication layers. Brute force is far more likely to degrade your server's performance than to actually compromise credentials.
That second use case, the performance hit, is the one most guides overlook. Even when every login attempt fails, the attack still costs you something.
Two Doors Attackers Use: wp-login.php and xmlrpc.php
WordPress exposes two authentication endpoints, and most site owners only know about one of them.
The Login Page (wp-login.php)
This is the obvious target. Bots send automated POST requests to /wp-login.php with username-password combinations. At high volume, each request triggers a full PHP execution cycle: WordPress bootstraps, looks up the user in the database, runs a bcrypt password hash (intentionally slow at roughly 100 milliseconds per attempt), and executes all security hooks.
At 100 requests per second, this can consume all available PHP workers on a typical hosting environment. Legitimate visitors start seeing 502 and 503 errors. Your site is effectively offline, not because it was hacked, but because the server is too busy processing failed login attempts to serve real pages.
WordPress XMLRPC Brute Force: The Hidden Door
XML-RPC is WordPress's legacy remote publishing API, enabled by default on every installation. Most site owners have never heard of it. Most security guides barely mention it. And it's a significantly more dangerous brute force vector than the login page.
Here's why. The system.multicall method in XML-RPC allows attackers to bundle hundreds of authentication attempts into a single HTTP request. A script running 1,000 iterations with 1,000 method calls each can attempt one million logins in minutes, all appearing as relatively few HTTP requests in your traffic logs.
This creates two problems. First, standard login-limiting plugins only monitor wp-login.php, so WordPress XMLRPC brute force authentication rarely triggers lockout counters. Second, because requests are bundled, the attack is harder to detect. Your server logs show a modest number of requests while the actual authentication load is orders of magnitude higher.
A single malicious XMLRPC.php request containing 500 credential attempts triggers 500 separate bcrypt operations. At just 10 requests per second, that's 5,000 password hash computations per second, enough to bring down most servers.
Most sites don't need XML-RPC at all. Jetpack was the last major dependency, and even Jetpack has moved to the REST API. If your site doesn't use XML-RPC for a specific integration, it should be disabled entirely. And "disabled" means blocked before it reaches your server, not handled by a plugin that still executes PHP to evaluate and reject the request.
The Reconnaissance Step
Brute force is often preceded by user enumeration, where attackers scan WordPress's default author profiles to collect valid usernames. WordPress hands this information over freely: the author URL slug matches the actual login username by default. Once an attacker has your usernames, they only need to guess passwords rather than both halves of the credential pair.
This is why user enumeration and brute force should be addressed together. Stopping enumeration forces attackers to guess usernames too, which dramatically reduces the efficiency of any brute force attempt.
The Hidden Cost of Failed Attacks
Most articles frame brute force risk as "someone might guess your password." That misses the operational impact entirely.
Every wp-login.php POST request triggers a chain of expensive operations: PHP process allocation, WordPress core bootstrap, a database connection and user lookup query, bcrypt password hashing, and security hook execution. On shared hosting, other sites on the same server are affected too. Hosts may even suspend your account for exceeding resource limits, even though you're the victim.
On VPS or dedicated hosting, sustained brute force attacks cause visible CPU and memory spikes. PHP workers queue up. Response times climb. Real visitors experience a slower site without any obvious explanation.
Then there's the alert fatigue. Security plugins proudly report "10,000 attacks blocked this week." What that actually means is your server processed 10,000 malicious requests at the PHP level before blocking them. Each one consumed server resources. Each one was a request your server should never have seen.
This is the performance tax of application-level brute force protection. The attacks are blocked, but the blocking itself has a cost.
How to Stop WordPress Brute Force Attacks with Layered Defense
Search for "WordPress brute force protection," and nearly every result recommends installing a plugin. Wordfence, Limit Login Attempts Reloaded, Solid Security, or something similar. These are legitimate tools with millions of active installations. But they all share the same architectural limitation: they block attacks after the traffic has already reached your server.
The defense hierarchy that actually works has three layers, and the order matters.
Layer 1: Edge Protection (Most Important)
The most effective WordPress brute force protection happens before traffic reaches your server. A DNS-level web application firewall like Cloudflare filters requests at the CDN edge, meaning malicious login attempts never consume your server's bandwidth, PHP workers, or database connections.
For our fleet of roughly 200 WordPress sites, edge protection looks like this:
Rate limiting on wp-login.php. POST requests to the login page are limited to 5 per minute per IP. This stops automated tools immediately while allowing legitimate users (who rarely fail more than two or three times) to log in normally.
Complete XMLRPC.php block. Since none of our sites require XML-RPC, we block it entirely at the edge. Zero server load, zero risk, zero PHP execution. This eliminates the WordPress XML-RPC brute force vector completely.
Managed challenges on login pages. Before a login request reaches the server, the WAF requires the browser to prove it's not a bot. Automated scripts fail this check. Real users pass it without even noticing.
Author enumeration blocking. Requests containing the ?author= parameter are blocked at the edge, preventing the reconnaissance step that precedes brute force.
The key point: with edge protection properly configured, brute force traffic never reaches WordPress. There's no PHP execution, no database query, no server resource consumption. The "10,000 attacks blocked" metric becomes a Cloudflare dashboard statistic rather than a server workload.
Layer 2: Application-Level Login Protection
Edge protection handles the bulk of brute force volume, but distributed attacks can still slip through. Attackers using residential proxy networks or rotating through thousands of IPs may stay under rate limits. This is where application-level protection provides a second line of defense.
At this layer, we configure lockouts after five failed login attempts, with progressive escalation: 4 hours for a first offense and 24 hours for subsequent attempts. Attempts using "admin" or "administrator" as usernames get locked out immediately, since those are never legitimate on properly configured sites.
The difference from a plugin-only approach is volume. When edge protection handles 99%+ of brute force traffic, the application layer only needs to catch stragglers. It processes a handful of suspicious requests per day rather than thousands. The server impact is negligible.
Layer 3: Authentication Hardening
The final layer ensures that even if an attacker gets past rate limiting and guesses a correct password, they still can't log in.
Two-factor authentication is the most impactful measure here. 2FA adoption among WordPress users reached 70% in 2025, making it the most widely adopted WordPress security measure. MFA results in approximately a 73% reduction in unauthorized login attempts, largely because attackers detect 2FA and move on to easier targets.
2FA effectively eliminates brute force as a viable attack vector. Even with the correct password, the attacker can't complete authentication without the second factor.
For authentication methods, TOTP authenticator apps (Google Authenticator, Authy, 1Password) provide the best balance of security and usability. Hardware security keys are stronger but impractical for most organizations. Email-based codes are acceptable. SMS codes are the weakest option due to SIM-swapping risks, but they're still better than nothing.
Passkeys and WebAuthn represent the next evolution of login security. Passkeys replace passwords entirely, using cryptographic key pairs tied to a device or a password manager. Because there's no password to guess, brute force becomes fundamentally impossible, not just impractical.
WordPress support for passkeys is still maturing, but major password managers and browsers already support the standard. For organizations planning their security roadmap, passkeys are worth watching. They could make this entire category of attack obsolete.
Strong password policies matter too. Minimum 16-character passwords for admin accounts, password manager usage to eliminate reuse, and blocking the top 10,000 most common passwords. The "admin" username should not exist on any site. 81% of successful WordPress compromises stem from insecure or stolen passwords, making credential quality the last line of defense.
Defense Hierarchy Summary
| Layer | Defense | What It Stops | Server Resource Cost |
|---|---|---|---|
| Edge (Cloudflare WAF) | Rate limiting, bot management, IP reputation | High-volume attacks before they reach PHP | None (handled at CDN) |
| Application (WordPress) | Login lockout, username validation, CAPTCHA | Attacks that pass WAF thresholds | Moderate (PHP processes each request) |
| Authentication | Strong passwords, 2FA, passkeys | Credential compromise | Minimal |
Why IP Blocking Alone Falls Short
A common response to brute force is to block the attacking IP addresses. This worked reasonably well a decade ago. It doesn't work against modern attacks.
Modern botnets use tens of thousands of unique IPs. A well-documented 2024 campaign used approximately 90,000 compromised servers. Blocking one IP has negligible impact when the attacker has 89,999 more.
Residential proxy networks route attacks through legitimate home IP addresses, making IP reputation lists unreliable. Cloud provider IPs from AWS, Azure, and Google Cloud are shared, and blocking them risks blocking legitimate visitors too.
Credential stuffing makes IP blocking even less effective. Each IP makes only one or two attempts, well under any rate limit, then rotates to the next. There's no volume spike to detect at the individual IP level.
IP blocking is one tool in the toolbox, not a strategy. Effective WordPress brute force protection combines edge rate limiting for volume-based attacks, behavioral analysis for slow-and-low attacks, 2FA to render stolen credentials useless, and username enumeration prevention to force attackers to guess both halves of the credential pair.
The Evolving Threat: Browser-Based Botnets
The brute force landscape continues to evolve. In 2024, Sucuri documented a novel attack in which compromised WordPress sites injected JavaScript that hijacked visitors' browsers to perform brute force attacks against other WordPress sites.
Each visitor's browser became an unwitting attack node. Over 700 WordPress sites were identified as staging grounds, many initially breached through compromised plugins. The attack traffic came from legitimate visitor IP addresses, making it extremely difficult to block with traditional methods.
This represents a shift from server-based botnets to browser-based distributed computing for attacks. WordPress's own ecosystem is being weaponized against itself. Brute force defense isn't a set-and-forget proposition. The attack methods keep evolving, and protection needs to evolve with them.
A Note on Security Through Obscurity
One piece of advice you'll see in nearly every brute force protection guide is to move your WordPress login URL. Change /wp-login.php to /my-secret-login or something similar.
We don't do this. Bots find the moved location anyway. And clients lose track of their login URL or lock themselves out using the plugins that handle the redirect. It's not inherently a bad idea, but we have better protections in place, so we don't rely on it.
If your brute force protection strategy depends on hiding your login page, that's a sign the actual protection layers need work.
What Protection Looks Like at Scale
Most WordPress security advice is written for individual site owners. Install this plugin, configure these settings, monitor your login logs. That approach doesn't scale.
When you manage dozens or hundreds of WordPress sites, plugin-based brute force protection means configuring, updating, and monitoring a security plugin on every single site. A WAF rule change requires touching every installation. An xmlrpc.php block needs to be applied 200 times.
Infrastructure-level protection applies once and covers everything. A single Cloudflare WAF rule that blocks xmlrpc.php deploys across our entire fleet simultaneously. A rate-limiting policy on wp-login.php protects every site without per-site configuration. Attack patterns observed at one site inform protection across all others through shared threat intelligence.
This is a fundamentally different approach from what most guides describe. It's the difference between 200 individual security configurations and one unified policy.
When to Take Action
If you're seeing repeated failed login attempts in your security plugin dashboard, that's normal. Every WordPress site on the internet experiences this. The question isn't whether it's happening but whether your protection is in the right place.
If your security plugin is blocking thousands of attempts per week, your server is processing thousands of malicious requests per week. That's the plugin working as designed, but it also means your infrastructure is doing work it shouldn't need to do.
If your site slows down periodically without explanation, check whether login page traffic correlates with the slowdowns. Brute force often shows up as a performance problem before it ever becomes a security problem. The same is true of spam registrations, where throttled bots create fake accounts that gradually degrade database performance.
The right response depends on your situation. For sites with professional security management, edge-level protection should handle the bulk of brute force traffic before it reaches WordPress. For sites without that infrastructure, application-level plugins like Wordfence provide meaningful protection, even if they carry a server resource cost.
Either way, two-factor authentication should be enabled for every admin and editor account. It's the single measure that renders brute force irrelevant as a credential-theft vector.
Getting This Right
Brute force attacks aren't going away. The volume is increasing, the methods are getting more sophisticated, and the infrastructure behind them continues to grow. But the defensive tools have grown too.
A properly configured Cloudflare WAF stops the vast majority of attempts before they consume a single server resource. Application-level protection catches what slips through. And two-factor authentication makes the entire category of credential theft irrelevant.
The key is understanding that brute force protection isn't a single tool. It's a hierarchy, and where each layer sits determines how much your server pays for the protection.
"Anyone who's guaranteeing you 100% security is a fool. What we guarantee is that we have the best tools, practices, and services in place, plus rapid response and recovery when something does happen."
Frequently Asked Questions
Is my WordPress site being brute forced right now?
Almost certainly yes. Every WordPress site on the internet gets probed by automated bots testing login credentials. If you have a security plugin installed, check its activity log and you'll likely see failed login attempts. The average WordPress site faces a login attack every 28 minutes. The question isn't whether it's happening. The question is whether your protection is stopping it at the right layer.
Do I need a security plugin for brute force protection?
A security plugin is better than nothing, but it's not the best approach. Plugins like Wordfence block attacks after the traffic has already reached your server, which means your server still has to process every malicious request before rejecting it. A web application firewall at the network edge, like Cloudflare, stops brute force traffic before it ever reaches your server. That's a meaningful difference when you're dealing with thousands of login attempts per day.
Does changing my WordPress login URL help?
It can reduce the volume of automated scans that target the default /wp-login.php path, but it's not a real security measure. Determined bots find the new URL anyway, and we've seen clients lock themselves out by forgetting their custom login path. If you need to hide your login page to feel secure, that's a sign your actual protection layers need work. Rate limiting, two-factor authentication, and edge-level WAF protection are all more effective.
What's the most important thing I can do to stop brute force attacks?
Enable two-factor authentication on every admin and editor account. It's the single measure that makes brute force completely irrelevant as a credential theft vector. Even if an attacker guesses the right password, they can't complete the login without the second factor. 2FA adoption among WordPress users hit 70% in 2025, and for good reason.
Why does my site slow down during brute force attacks?
Every failed login attempt triggers a full PHP execution cycle on your server. WordPress has to load its core files, connect to the database, look up the username, run a password hash computation, and execute security hooks. Multiply that by hundreds or thousands of attempts per hour and your server runs out of resources to serve actual visitors. This is why brute force is as much a performance problem as it is a security problem, and why blocking attacks at the network edge matters.
If you're not sure whether your current setup is handling brute force attacks at the right layer, or if your security plugin is doing work that should happen upstream, our WordPress security services can help you assess what's in place and what's missing. You can also read more about why organizations choose FatLab for WordPress security and how our approach differs from plugin-first security providers.