WordPress Brute Force Attack: How to Block It in 2026

Right now, automated bots are trying to guess the password on your WordPress login page. They never sleep, they never get tired, and they cost almost nothing to run. In 2025, 94% of all login attempts across Cloudflare’s network came from bots rather than real people. For WordPress, the software behind 41.5% of the web, that volume turns the humble wp-login.php page into the single most attacked door on most sites.

This guide explains exactly how a brute force attack works, why these attacks still succeed in 2026, and seven methods to block them. Some take two minutes. Some need a developer. Together we shut the door.

Brute force defense is one layer of a larger plan. Pair it with our complete WordPress security best practices checklist for the full picture.

Key Takeaways

• 94% of login attempts on the web are automated bots, and 46% of the human attempts use passwords already found in breach databases (Cloudflare, March 2026).
• A brute force attack guesses username and password combinations until one works. WordPress is targeted heavily because it powers 43% of all websites.
• Two-factor authentication blocks over 99% of automated account-takeover attempts.
• 78% of the world’s most common passwords can be cracked in under one second, according to NordPass.
• Limiting login attempts, protecting xmlrpc.php, and adding a firewall close the gaps that brute force bots rely on.

What Is a WordPress Brute Force Attack?

A brute force attack is an automated attempt to log in by trying thousands of username and password combinations until one works. Account takeover attacks rose 40% year over year in 2025, and WordPress sits at the center of that wave. The attacker doesn’t need to know your password. The bot just guesses, over and over, at machine speed.

There are different ways of the same attack. A classic brute force tries common passwords against a known username. A dictionary attack runs through lists of real-world passwords leaked in past breaches. Credential stuffing reuses email and password pairs stolen from other sites, betting that people recycle the same login everywhere. All three hammer the same WordPress endpoints.

The default WordPress admin username used to be “admin,” and many older installs still use it. That hands attackers half the puzzle for free. When the username is known and the password is weak, a brute force bot can succeed in seconds.

For the broader task of securing your dashboard, our step-by-step guide to securing your WordPress site provides a detailed walkthrough of the wp-admin area.

How Common Are Brute Force Attacks on WordPress in 2026?

Brute force attacks are now the default background noise of the web, not a rare event. In 2025, automated traffic overtook human traffic for the first time in a decade, reaching 51% of all web activity, with bad bots alone climbing to 37%. Login pages absorb a huge share of that bot volume.

Bots Took Over the Web in 2025

The Cloudflare data makes the scale concrete. Across its network in 2025, 94% of all login attempts were automated, and nearly half of the remaining human attempts 46% used credentials already exposed in known breaches. So the login form is not mostly serving your customers. It’s mostly serving attackers.

Who Is Actually Logging In? (Cloudflare 2026 Threat Report)

[Our insight] The reason WordPress draws so much fire isn’t that it’s insecure by design. It’s predictable. Every standard install has the same login URL, the same database table prefix patterns, and the same XML-RPC endpoint. A bot doesn’t need to study your site. It already knows where the door is before it arrives, which is why the same attack script works against millions of targets without modification.

Why Do Brute Force Attacks Still Work?

Brute force attacks keep working because people reuse weak passwords and most sites never limit login attempts. The 2025 Verizon DBIR found that stolen or compromised credentials were the initial access route in 22% of all breaches, and 88% of basic web application attacks used stolen credentials. Weak passwords are the fuel, and an open login form is the engine.

The password problem is worse than most owners think. NordPass found that 78% of the world’s most common passwords can be cracked in under one second, and “123456” remains the single most used password globally. When an admin uses a password from that list, a brute force bot isn’t really guessing. It’s reading from a script.

Password reuse compounds the risk. Verizon’s analysis of single sign-on logs showed that only 49% of a typical user’s passwords were unique, and credential stuffing made up roughly 19% of all authentication attempts. One leak on an unrelated site can hand an attacker a working WordPress login.

There’s a second engine specific to WordPress: the xmlrpc.php file. Its system.multicall method lets an attacker bundle up to roughly 1,999 login guesses into a single request. Standard rate limiters that count requests per IP see one hit and wave it through, while thousands of password guesses run behind it.

[Our Experience] In site audits, the pattern repeats constantly. The admin account uses a short password, the “admin” username is still active, there is no login attempt limit, and xmlrpc.php answers every request. Each gap on its own feels minor. Stacked together, they turn a routine bot scan into a full account takeover within a single afternoon.

Strong, unique credentials are the foundation here, a habit we cover in our WordPress security best practices and tips.

How to Block WordPress Brute Force Attacks (7 Methods)

You block brute force attacks by removing the things bots depend on: weak passwords, unlimited guesses, a known login URL, and an open XML-RPC endpoint. Two-factor authentication alone stops over 99% of automated account-takeover attempts. The seven methods below run from quickest to most thorough. Most sites should apply the first four.

Method 1: Use Strong, Unique Passwords and Drop the “admin” Username

Set a password of at least 16 random characters for every administrator account, generated and stored in a password manager. Then remove any account named “admin.” Create a new administrator with a unique username, log in as that user, and delete the old one, assigning its posts to the new account.

This single step removes the easiest win attackers have. A 16-character random password is not on any cracking list, and an unknown username forces bots to guess both halves of the login instead of one.

Method 2: Turn On Two-Factor Authentication (2FA)

Two-factor authentication is the most effective control you can add. Even with a correct password, an attacker is stopped by the second factor. Microsoft reports that 2FA blocks over 99% of automated account-takeover attempts, while 97% of identity attacks remain simple password spraying and brute force.

Plugins such as Wordfence Login Security, WP 2FA, or miniOrange add app-based codes (TOTP) to every login. Require it for all administrator and editor accounts, not just your own.

The Case for 2FA and Strong Passwords (Source: Microsoft, NordPass)

Method 3: Limit Login Attempts

Cap how many failed logins an IP address gets before it’s locked out. A brute force attack relies on unlimited guesses, so a limit of five attempts followed by a 20-minute lockout ends most automated runs instantly. Plugins like Limit Login Attempts Reloaded or the login features in Wordfence and Solid Security handle this.

Set a low threshold, a rising lockout duration for repeat offenders, and email alerts so you can see when an attack starts. This is the single fix that turns a flood of guesses into a handful.

For a hands-off setup, see how to build an automated WordPress security system that handles lockouts and monitoring for you.

Method 4: Protect or Disable xmlrpc.php

If you don’t use the Jetpack plugin, the WordPress mobile app, or another XML-RPC integration, block the file at the server level. This closes the amplification route that lets one request carry close to 2,000 guesses.

Apache (.htaccess):

<Files xmlrpc.php>
  Order Deny,Allow
  Deny from all
</Files>

Nginx (server block config):

location = /xmlrpc.php {
    deny all;
    access_log off;
    log_not_found off;
}

The access_log offline matters during an active attack. A flood of blocked requests can fill a log file with gigabytes of noise in hours, so silencing that one endpoint protects your disk.

Closing unused entry points like this is core to hardening. Our step-by-step guide to securing your WordPress site covers the rest.

Method 5: Add a Web Application Firewall (WAF)

A WAF inspects traffic before it reaches WordPress and drops known attack patterns. This matters because traditional defenses are weak against WordPress-specific threats. Patchstack found that 46% of WordPress vulnerabilities had no developer fix available at disclosure, with a median of just five hours from disclosure to first mass exploitation.

Cloudflare’s free tier, Wordfence, or Sucuri all provide a firewall that recognizes brute force signatures and rate-limits attackers across their whole network, not just your single site.

Method 6: Hide or Rename the Login Page

Most bots target /wp-login.php and /wp-admin directly. Moving your login to a custom URL like /secret-door makes the automated scans miss it entirely. Plugins such as WPS Hide Login change the path in seconds.

This isn’t a complete defense on its own, since a determined attacker can still find the new path. But against the automated scripts that generate the bulk of attacks, it removes you from the target list. Pair it with a CAPTCHA on the login form to stop the bots that do find the page.

Method 7: Use Hosting and Server-Level Protection

Managed WordPress hosts often block brute force attacks at the network edge before they ever reach your site. Confirm that your host offers login rate limiting, IP reputation filtering, and a WAF. If it doesn’t, that’s a strong reason to move.

For self-managed servers, tools like WPFail2ban watch authentication logs and ban offending IPs at the firewall. This stops the attack outside PHP entirely, which saves server resources during a heavy flood.

If running this yourself isn’t realistic, our WordPress performance and security service handles server-level protection and monitoring for you.

How Do You Know If Your Site Is Under a Brute Force Attack?

You can spot a brute force attack before it succeeds by watching four signals. Because WordPress vulnerabilities jumped 42% in 2025 to 11,334 new entries, proactive monitoring is no longer optional. Most owners only notice an attack when they’re locked out, by which point it’s too late.

• A spike in failed login notifications. Your security plugin logs failed attempts. A jump from a few per week to hundreds per hour means an attack is running. Set email alerts so you hear about it immediately.
• Unexplained server CPU or memory spikes. Brute force floods consume PHP threads. If your hosting dashboard shows resource spikes without matching visitor growth, the load is coming from attack traffic, not readers.
• Repeated POST requests to wp-login.php or xmlrpc.php. Check your server access logs for clusters of POST requests to these files from many different IPs in a short window. That pattern is the fingerprint of a brute force run.
• Account lockout emails you didn’t trigger. If you receive lockout notices for an admin account while you’re not logging in, someone else is trying the password. Treat it as a live attack and confirm your defenses are active.

If you see these signs, apply Methods 2 through 4 immediately and contact your host with the log timestamps. A site under active attack needs the login limit and XML-RPC block in place first.

Frequently Asked Questions: Brute Force Attack

Conclusion

Brute force attacks are not a question of if but of how often. With 94% of login attempts now automated and 78% of common passwords crackable in under a second, every WordPress login page is a live target. The good news is that the fixes are well understood and mostly free.

Start today with the four core steps: set strong, unique passwords, turn on two-factor authentication, limit login attempts, and protect xmlrpc.php. Those alone remove the conditions nearly every brute force bot depends on. Add a firewall and server-level protection for sites that need the strongest defense.

The bots aren’t going to stop. But a locked door they can’t pick is one they move on from. Close the gaps now, before the next scan finds them. For everything beyond brute force, work through our complete WordPress security best practices checklist and lock down the rest of your site.