WordPress Brute Force Attacks: Your Login Page Is Under Constant Assault

During our Monday morning operations review, a familiar pattern jumped off the dashboard. We see it most weekends across our customer base. A small WordPress site, in this case the booking page for a boutique hotel on the Inishowen peninsula in Donegal, had logged tens of thousands of failed login attempts against /wp-login.php between Friday evening and Sunday night. The owner runs the site herself. Takes bookings. Posts photos. Sends out a Christmas voucher promotion every December.

As far as she could tell from her side of the screen, nothing was wrong. The site loaded. Bookings came through. The contact form worked.

That is what a brute force attack actually looks like in 2026. Not a smash-and-grab. A relentless, automated, distributed assault that does not announce itself, does not slow your site enough for you to notice, and does not write to any log you would ever check. The attack is constant. The owner has no idea. And the moment one of those attempts gets the password right, the business stops being the owner's.

What a Brute Force Attack Actually Looks Like

Strip away the headlines and a brute force attack is mechanical. A bot has a list of usernames it suspects exist on your site (admin, your name, your business name, anything it scraped from your About page). It has another list of passwords, hundreds of millions of them, harvested from previous breaches. It tries the combinations against your login endpoint, one after another, until something works.

WordPress makes this easier than it should be. The login page lives at a predictable URL on every WordPress site by default: /wp-login.php. The same goes for /xmlrpc.php, an older interface that allows multiple login attempts to be bundled into a single request, which attackers love because it amplifies their throughput. WordPress.org's own developer documentation flags both as standard brute force vectors ^[1].

Bots find these endpoints in seconds. They cycle through credentials at industrial scale. The tens of thousands of attempts against the Donegal hotel were not the work of a single attacker hammering the front door. They were a botnet, distributed across thousands of compromised devices and rented residential proxies, each contributing a few attempts before rotating out. That is why simply blocking one IP address barely scratches the surface anymore.

Why Bots Target WordPress Specifically

WordPress runs roughly 43 percent of the world's websites, according to W3Techs ^[2]. Even if a botnet operator takes a wild scattergun approach across the internet, almost half of what they hit is going to be a WordPress site. The sheer ubiquity makes it the most efficient target in the world.

Every WordPress site responds to the same login URL. Every WordPress install has a standard administrator account, even if the admin username has been changed. The /wp-json/users endpoint, designed for legitimate purposes, can leak a list of valid usernames on misconfigured sites. Once a bot has a real username, the password becomes the only thing standing between the attacker and full control of your site.

Wordfence, the security plugin running on millions of WordPress installations, blocks more than six billion brute force attempts every month across its network and reported tens of billions of password attack attempts blocked across 2024 ^[3]. AI-driven botnets, according to their threat intelligence, increased the volume of brute force traffic by close to half over the course of 2025. The numbers are eye-watering and they are still climbing.

The Numbers Are Worse Than Most Owners Think

The Verizon Data Breach Investigations Report, which I read every year because it sets the standard for incident analysis, made the picture clear in their 2025 edition ^[4]. Stolen credentials were the single most common initial access vector across every breach they analysed, used in 22 percent of cases. When you narrow it down to basic web application attacks, the figure rises to 88 percent. The vast majority of websites that get compromised are compromised because someone got the password.

The same report flagged something else worth noting. Small and medium businesses are being targeted roughly four times more than large organisations, and 88 percent of breaches involving SMBs included a ransomware component. The reason is uncomfortable. Smaller businesses are perceived, often correctly, as having weaker defences and less monitoring than enterprise targets. The attackers know exactly where the soft underbelly is.

If you run a local firm with a WordPress site, you are not too small to be a target. You are exactly the right size.

Why You Will Not Notice It Happening

Here is the part that catches owners off guard. A modern brute force attack is engineered not to show up. The traffic comes from thousands of different IP addresses, often residential, so it does not look like a flood from a single source. Volume is throttled per source so basic rate limiters miss it. The CPU usage on a properly hosted WordPress site barely flickers. The home page loads as fast as it always did.

What you might notice, if you are paying attention, is your wp-admin page feeling sluggish for ten seconds. Or an "account locked" email that you did not trigger. Or, in the worst case, the morning you cannot log in at all because the bots got in first and changed your password.

The Donegal hotel owner I mentioned at the top? She did not see any of it. Her bookings during that weekend were normal. The site was up. The only reason we knew is because we were monitoring the access logs at the server level. By the time she would have had reason to look, the damage would already have been done.

What Happens When the Attack Succeeds

A successful brute force compromise is not a clean, polite event. The attacker does not announce themselves. They install a backdoor, a piece of code hidden inside your theme files or in a plugin you would never inspect, that lets them return whenever they want. They might inject SEO spam linking out to gambling sites, which Google will eventually punish you for. They might silently siphon customer data from your contact forms or your WooCommerce orders. They might wait three months and then hold your entire database for ransom.

I have seen the aftermath of a successful brute force attack on a small business site more times than I care to count. The recovery is rarely quick. You are restoring from backups (assuming you have verified backups, which is a different conversation entirely), changing every credential, scanning every file for malicious payloads, and explaining to your customers why their data may have been exposed under the GDPR breach notification rules. None of that happens in a single afternoon.

For the Donegal hotel, the consequence of a successful login attempt that nobody noticed would have been a fortnight of disrupted bookings during peak season, a regulatory disclosure under GDPR, and a hard conversation with every guest whose contact details were on the system. That is the reality the owner was sitting on without knowing it.

What Real Protection Looks Like

Stopping brute force attacks properly is layered. There is no single switch. Anyone who tells you otherwise is selling something.

The first layer is at the network edge. Before a request even reaches your WordPress install, an upstream system should be rate-limiting login traffic per IP address, pattern-matching for botnet signatures, and dropping obviously malicious requests. This needs to happen at the server level, not inside WordPress, because by the time WordPress is processing the request you have already paid the CPU cost.

The second layer is intrusion detection. Tools like fail2ban watch the access logs in real time. When an IP address racks up a defined number of failed login attempts within a short window, fail2ban inserts a firewall rule blocking that IP at the operating system level for a set period. It is not perfect. Distributed botnets work around it. But it raises the cost of the attack and shuts down the lazy attempts that make up most of the volume.

The third layer is inside WordPress itself. Strong, unique credentials for every account. Two-factor authentication where your hosting platform supports it. Limiting login attempts at the application level. Locking down /xmlrpc.php if you do not use it. Removing unused administrator accounts.

The fourth layer is monitoring. You cannot defend against what you cannot see. The reason we caught the Donegal hotel's situation on a Monday morning was because we were watching the right logs at the right level. A site running on shared hosting with no log access has zero visibility into this.

A Mistake Worth Admitting

A few years back, before we tightened up our jail configurations across the platform, I trusted a fail2ban setup that I had not actually verified end to end. Looked fine on paper. Logs showed bans being applied. What I had missed was that the bans were being applied to the wrong chain in the firewall, so the "blocked" IPs were still cheerfully connecting. We caught it during a routine audit. Cost us nothing in the end, but it taught me to never trust a security control I have not deliberately tried to break. Verify, do not assume.

The Honest Limit

Here is what the brochure copy will not tell you. No brute force protection is bulletproof. A determined, well-resourced attacker with a botnet of half a million residential IPs can chip away at a login page slowly enough to evade most rate-limiting systems, especially if they target a username they already know is real. Two-factor authentication makes them roughly an order of magnitude harder to crack, but 2FA itself can be defeated by phishing, by SIM swap attacks, or by malware on the owner's own machine.

The realistic goal is not to make brute force attacks impossible. It is to make them expensive enough that the bot moves on to an easier target. WordPress sites are everywhere. Most attackers are looking for low-hanging fruit. Strong passwords, 2FA, server-level rate limiting, fail2ban, and active log monitoring together raise the cost enough that, statistically, the bot picks somebody else's site instead of yours. That is the honest framing.

Where Web60 Sits in This

When we built Web60, this layered model was the assumption, not the upsell. Every Web60 site runs behind Nginx with rate limiting on the login endpoints. Fail2ban is configured and verified. Strong credentials are enforced at signup. /xmlrpc.php is locked down by default unless a customer explicitly needs it. The infrastructure runs on our own Irish sovereign cloud platform, which means the access logs and the security response live with us, not with a third-party panel that the customer has to learn.

That is what we believe genuinely managed WordPress hosting should mean. Not a shared server with a fancy badge. A platform that is actively watching, actively blocking, and actively reporting on what is happening to your site at 3am on a Sunday when you are not.

If you are running enterprise-tier WordPress with a dedicated security operations team and a custom WAF stack, premium enterprise managed hosts genuinely suit that workload. Most owner-operators running a single business site do not need that, and would not get value out of it. They need a sensible, layered default that just works. That is exactly the gap Web60 was built for.

For the broader pattern of why small business websites are favourite targets for attackers, the data is fairly damning. The point of this article is narrower. The login page on your WordPress site is being hammered right now. You did not notice. That is the system working as designed against you, until somebody does something about it.

Conclusion

The Donegal hotel owner I started with does not know how close she came over that one weekend. She does not need to. The protection ran, the bots got nowhere, and she carried on running a business. That is the right outcome.

But it is not the default outcome. It only happens when the platform underneath the site is doing the unglamorous, methodical work of watching logs, banning IPs, enforcing rate limits, and verifying that the controls actually work. Most cheap shared hosting plans do not do any of that. The owner thinks they are paying for hosting; they are paying for a server that happens to host their site, with no operations team behind it. The day a brute force attack succeeds is the day they find out the difference.

The decision in front of every business owner running a WordPress site is whether to sit on that risk silently, or to put it onto a platform that handles it before the morning operations review surfaces a pattern that should have been blocked overnight.

Frequently Asked Questions

How do I know if my WordPress site is being brute forced?

Most owners cannot tell from inside WordPress. The signals live in the server access logs, which require log access at the host level. Look for repeated POST requests to /wp-login.php or /xmlrpc.php from rotating IP addresses, often hundreds or thousands per hour. If your hosting plan does not give you log visibility, that itself is a warning sign.

Will a security plugin like Wordfence stop a brute force attack on its own?

A plugin helps but it is not enough on its own. Plugins run inside WordPress, which means the request has already reached your server before the plugin can decide what to do with it. The first line of defence should sit at the server or network edge, not inside WordPress. Plugins are a useful second layer, not a complete solution.

Should I disable /xmlrpc.php to prevent brute force attacks?

If you do not use the XML-RPC interface, which is true for most modern WordPress sites, blocking it at the server level is sensible. It removes a known attack surface. If you do use it for a specific mobile app or Jetpack feature, your hosting platform should rate-limit it rather than block it outright.

How important is two-factor authentication on WordPress?

It is the single most effective measure most small business owners can take. Verizon's 2025 breach data shows the vast majority of web application breaches start with stolen or guessed credentials. Two-factor authentication breaks that chain because even a correct password is not enough on its own. Where your hosting platform supports enforced 2FA, turn it on.

Will moving to managed WordPress hosting actually stop brute force attacks?

A well-built managed WordPress platform handles the brute force layer at the infrastructure level so you do not have to think about it. Whether a specific provider does that competently is the question worth asking. Look for log visibility, fail2ban integration, rate limiting, and an operations team that monitors and responds. If the answers are vague, the protection probably is too.

Sources