Your WordPress Login Page Is Under Attack Right Now. You Just Cannot See It.

Reviewing our intrusion logs this morning, I counted the failed login attempts against one ordinary customer site over the previous day. They ran into the thousands. That site sells nothing controversial, holds no celebrity data, and belongs to a small practice almost nobody in the country has heard of. None of that matters to what is hitting it. To an automated attacker, your website is not a business. It is an address with a login form.

Here is a pattern we see often enough that it has its own folder in our incident notes. A physiotherapy clinic outside Galway runs a WordPress site that has worked fine for years. The bookings come in, the phone rings, the site does its job. One morning the enquiries stop. Not a trickle. Nothing. The owner logs in, and everything looks completely normal to them. Pages load. The booking form is there.

It is not normal. Search for the clinic by name and Google has wrapped a warning around the result: deceptive site ahead. Somewhere in the night, someone who was not the owner had logged into the WordPress admin and injected a few hundred lines of redirect code, the kind that quietly sends a share of visitors off to a payday-loan page or worse. The site was not breached through a clever exploit. It was breached through the front door. Someone typed the right password.

Nobody broke a window. They walked in with a key.

The attack you never see

When you picture a website being hacked, you probably picture a person. A hooded figure, a glowing screen, somebody choosing your business out of spite. The reality is more boring and far more relentless. The traffic trying your login page is almost entirely automated, and there is an astonishing amount of it.

According to the Thales 2026 Bad Bot Report, automated traffic made up roughly 53% of all web activity in 2025, with the genuinely malicious share, the bad bots, sitting around 40%. Treat those as reported figures rather than gospel, because methodology varies between security firms. The direction of travel is not in doubt though. More than half of everything moving across the internet is now machines, and a large part of that is hunting.

WordPress, because it runs close to half the web, is the favourite target. The security firm Wordfence, which publishes attack data from its own firewall network, reported blocking more than 100 billion credential-stuffing attacks against WordPress sites in 2023 alone. That is one vendor's count from one network, so read it as an indicator of scale rather than a precise census. The order of magnitude is the point. Credential stuffing, by Wordfence's own description, is the single most common type of attack against WordPress sites.

So what does that mean for the physio clinic, or for you? It means the assault is constant and completely indiscriminate. Your login page is being tried right now, today, while you read this, by software that never sleeps, never gets bored, and costs almost nothing to run. The attacker does not need to want you specifically. You are simply on the list, and the list is the entire internet. By the time anyone noticed the clinic's site was compromised, it had been redirecting patients for the better part of a week.

The password was the unlocked door

"Credential stuffing" sounds technical. The idea behind it is not. When a completely unrelated website suffers a data breach, the email addresses and passwords from that breach end up on lists that circulate freely online. Attackers take those millions of known email-and-password pairs and try them, automatically, against every login form they can find. Including yours.

This works for one simple reason: people reuse passwords. Survey figures vary, but a range of studies put it somewhere between two-thirds and three-quarters of people, with one widely cited Google and Harris Poll survey landing near 65%. Think about what that means in practice. The password protecting your business website might be the same one you used for a hobby forum you forgot about in 2019, a forum that has since been breached and dumped online.

The attacker did not guess it. They already had it.

So the uncomfortable truth about the clinic is that the door was effectively unlocked before anyone tried the handle. The admin password had been reused, it had surfaced in an old breach, and the automated tools simply found the match. No skill involved. Just patience and a long enough list.

I will admit I learned this one the slow way. Early on I trusted a simple login-lockout plugin to handle this on a site I looked after, and assumed that was the job done. A determined credential-stuffing run spread its attempts across thousands of different addresses, slipped under the plugin's per-address limit, and barely registered. Counting failures on one address, it turns out, is not the same as watching the whole pattern.

Why most hosting never catches it

Here is where the hosting decision actually bites, and where most providers quietly let you down.

Stopping this kind of attack is not a product you buy once and forget. It is an ongoing operations job. Something has to watch every login attempt across the whole server, recognise the signature of an automated run, and block the source before it gets through. All day, every day, without anyone clicking a button. That is monitoring and intrusion prevention, and it is unglamorous work that lives entirely in the background.

Most cheap hosting does not do it. You get a server, a WordPress install, and a login page facing the open internet with nothing in front of it. There may be a support ticket queue for when things go wrong, but a ticket queue is not a defence. It is a place to report the damage after the event. The gap that matters here is the one between a host actively watching your site around the clock and one that simply waits for you to file a ticket once a customer has already complained.

When a credential-stuffing run succeeds at 3am on a host with no operations layer, nothing stops it and nothing flags it. The first you hear of it is a customer ringing to say your site is sending them somewhere strange, or Google quietly delisting you from search. By then the clean-up, not the attack, is the expensive part. This is the difference between hosting that is sold as managed and hosting that is actually managed.

What actually stops it at the front door

A proper defence at the login layer is not one clever feature. It is a handful of plain mechanisms working together, none of which should be your job to configure.

• Rate limiting and lockouts. After a handful of failed attempts, further tries from that source are slowed or blocked, so a machine cannot fire thousands of guesses a minute.
• Server-level intrusion prevention. Rather than counting failures on a single page, the server watches login behaviour across every site it hosts and bans offending addresses outright. This is what catches a distributed run that any single plugin would miss.
• A locked-down login surface. Older entry points such as the XML-RPC interface, which attackers favour because it lets them bundle many password guesses into one request, are closed or restricted where they are not needed. WordPress documents this attack surface in its own security handbook on brute force attacks.
• Strong, unique credentials and, where your host supports it, multi-factor authentication, so that even a correct password is not enough on its own.

Notice that last point is deliberately qualified. Multi-factor authentication is one of the strongest controls available, and Wordfence names unique passwords plus MFA as the best defence against exactly this attack. But whether you can actually switch it on depends on your platform. Do not assume it is there. Verify it.

This is the standard we built Web60 to meet. Every site runs behind server-level security hardening and fail2ban intrusion prevention, which is the piece doing the unglamorous work described above. It watches failed login attempts across the platform and automatically bans the addresses behind an automated run before they can grind through a password list. In practice, that means the bot hammering your login page tonight is shut out after a few attempts instead of being left to try a million, and you never even know it happened. Automatic malware scanning sits behind that to catch anything that does slip through, and automatic nightly backups with one-click restore mean even a worst case is a bad morning rather than a rebuild from nothing. All of it runs on enterprise-grade Irish infrastructure that does this watching around the clock, with no setting for you to find. That is rather the point. The protections that genuinely stop credential stuffing are the ones that are on by default, not the ones buried in a panel you were never going to open.

Where this approach is not enough

I would be doing you a disservice if I pretended any of this makes a site untouchable. It does not, and two honest limits are worth stating plainly.

First, intrusion prevention and lockouts stop automated, at-scale attacks, which is the overwhelming majority of what you face. They do far less against a targeted, real-time phishing attack. Wordfence makes this point well: a modern phishing kit can sit between you and your real login, capture your password and even your one-time MFA code as you type them, and pass both straight to the attacker. No server-side lockout helps there, because from the server's point of view it is you logging in. The defence against that one is you. Be suspicious of any link asking you to log in, and check the address in the bar before you ever type a password.

Second, your own password hygiene still matters. If you reuse a breached password everywhere and switch off every protection you can find, no host on earth fully saves you from yourself. Good hosting narrows the attack surface dramatically. It does not abolish it.

There is also a genuine case where heavier, hands-on tooling beats an all-inclusive managed approach. If you run a security-sensitive platform with a dedicated technical team that wants to tune its own web application firewall rules, write custom lockout logic, and own every layer of the stack, a self-managed setup or an enterprise host with granular security controls genuinely gives that team more to work with. That is a real advantage for them. It is also not the physio clinic, the solicitor, or the shop owner reading this, for whom another security dashboard to manage is not freedom. It is one more thing to get wrong.

The lesson the clinic took away

The clinic got its site back. The backup turned the restore into a few hours of work rather than a few weeks of rebuilding, the redirect code was gone by lunchtime, and Google lifted the warning once the site was verified clean. If you want the fuller picture of how login defences, malware scanning and recovery fit together, our complete WordPress security and backup guide for Irish sites lays it out end to end. The clinic was lucky it was caught when it was. Plenty are not.

The lesson is not that WordPress is dangerous. WordPress runs close to half the web precisely because it is solid and proven. The real lesson is that the login page is a door onto a public street, and on the modern internet that street is crowded with machines trying every handle they pass. Someone, or something, has to be standing at that door. The only honest question is whether that job belongs to you and a plugin you hope is paying attention, or to a platform that treats it as routine operations and never asks you to think about it.

Worth knowing which one you have, before the quiet morning when the enquiries stop.

Sources