One morning I opened the login stats for our own website and saw a number I wasn’t expecting. 429 failed login attempts. In a single day. A few days earlier the peak had been close to 900.
My first thought was probably the same one you’d have. Is the password too weak? Are we about to be hacked? But it turned out the problem wasn’t the password at all, it was something far more ordinary. And the fix needed neither an expensive security plugin nor a consultant.
This is about WordPress security for you as a business owner, not for a developer. What actually gets sites hacked, what can you do yourself in an afternoon, and what can you genuinely stop worrying about?
Where the risk actually sits
The first thing worth clearing away is a common feeling: that WordPress itself is insecure. That isn’t quite true.
The security firm Patchstack reviews every new vulnerability found in the WordPress world each year. For 2025, around nine in ten sat in plugins, with almost all the rest in themes. WordPress itself, the core, accounted for just six, all of them low severity. In other words, your risk lives in what you add on top of WordPress, not in WordPress itself.
You sometimes hear that most hacked sites run WordPress. That says less than it sounds. WordPress runs such a large slice of the web that it comes out on top in almost any count like that. It says more about how common WordPress is than about how secure it is.
So where does the risk sit, concretely? In two places: your plugins and your login. The rest of this article is about those two.
How the bots actually get in
They guess your password, but they need the username first
Most attacks on a small website aren’t targeted. They’re automated programs, bots, that probe thousands of sites at once around the clock. They simply try to guess their way in through the login page.
To log in, you need two things: a username and a password. And here our own mistake was instructive. WordPress was leaking our username for free, through two addresses anyone could open. A list of the site’s users, and an old link type that led straight to the account name.
So the bots already had half the key. They only had to guess the password. That’s why we were seeing hundreds of attempts a day.
The interesting part is the fix. We didn’t install a heavy security plugin to block the attempts. We closed the leak. A couple of lines of code in the theme shut those two addresses for visitors who aren’t logged in, so the username was no longer handed out for free. That didn’t make the site untouchable, and it doesn’t replace two-factor login or a limit on login attempts. But it removed information that should never have been left in the open. We treated the cause, not just the symptom.
A plugin has a hole
The other way in is through a plugin. Remember that nine in ten vulnerabilities sit right there?
Most plugins are perfectly fine. The problems start when a plugin stops being maintained. The developer loses interest, nobody patches the holes anymore, but the plugin stays installed and keeps working, apparently. It’s like a window that looks shut but has broken in the frame.
The worst are so-called nulled plugins, pirated copies of paid versions. They’re often free for a reason: someone has built in a backdoor. And in 2026 a real supply-chain attack showed why trusting a plugin is no longer only about how often it updates. A buyer took over around thirty established plugins through the Flippa marketplace, slipped a backdoor into an ordinary update and let it sit dormant for eight months before it activated in April 2026. That means the advice to “update everything” still holds, but no longer covers the whole distance. Fewer, carefully chosen plugins are a safer foundation.
What you can do yourself, without heavy plugins
The good news is that you can influence a lot of this yourself, without paying for a big security suite that grinds away in the background on every page load.
Clear out the plugins. Every plugin you don’t use is a door you don’t need. Go through the list and remove anything you don’t actively benefit from.
Check the health of the ones you keep. On each plugin’s page on WordPress.org you can see when it was last updated, how many people use it, and whether it carries a warning that it’s untested or closed. A plugin untouched for a year is a warning sign.
Protect the login. A long, unique password is the foundation, but the single strongest protection against guessing bots is two-factor login, a code from your phone on top of the password. Add a limit on the number of login attempts too.
Keep PHP current. PHP is the engine that runs WordPress, and an old version is both slower and less secure. More on that shortly.
Notice what isn’t at the top of the list: “install a big security plugin.” For a simple business site that’s often more than you need, and the measures we used are a few lines of code that only run where they’re needed, with no noticeable effect on how fast the site loads. If you run a webshop, a membership site, or a site with many users, a proper security layer can be well worth it. The point is to choose by need, not out of worry.
The parts that need a little more
Some of security isn’t a one-off fix but something that has to be kept alive. Three things are worth a look of their own.
The PHP version. More than a third of WordPress sites run a version of PHP that no longer gets security updates, according to WordPress.org’s own statistics in October 2026. When PHP 8.2 stops getting security updates at the turn of the year, that becomes a majority. As a rule of thumb, a business site should therefore be on PHP 8.3 or newer, which gets security updates until the end of 2027. You can usually see which version you’re on under Tools and Site Health in WordPress, and switching is often a couple of clicks at your host. But it should be tested first, so nothing stops working.
Updates without crashing the site. Hitting “update all” straight on the live site is the most common way to accidentally break something. Security updates should go in quickly, but larger updates do better tested on a copy first.
Backups you can actually restore. A backup is worthless the day it won’t roll back. What matters isn’t only that copies exist, but that someone checks now and then that they really work.
See the pattern? This is ongoing work, and that’s exactly why many people choose to hand it to someone else.
When the plugins themselves become the risk
Sometimes the answer isn’t a better plugin, but fewer plugins.
As a site grows it’s easy to accumulate a plugin for every little feature. One for forms, one for booking, one to show reviews, one for a calendar. Soon a handful of different developers each run a piece of your website, and each one is a possible way in.
For recurring, business-critical functions, it can then pay off to build your own custom solution instead. One thing to keep track of instead of five, built to do exactly what you need, without a foreign update channel running straight into the site.
But be honest with yourself about when it doesn’t pay off. For everyday functions like forms, payments, or search-engine optimisation, a mature, well-maintained plugin is usually safer than custom code only one person understands. The goal is a small, vetted set of plugins, not zero.
If the worst does happen
Imagine a site with a contact form or a shop gets hacked. Then it isn’t just your own downtime at stake, it’s your customers’ data.
In the eyes of the law it can be a personal data breach, and then a clock starts. Unless the breach is unlikely to put anyone at risk, you have three days from discovering it to report it to the supervisory authority (in Sweden, IMY), and if the risk is high, the customers affected have to be told as well.
This deserves its own walkthrough, and we cover the whole sequence in a separate article. But the point here is simple: security on a business site isn’t only about the site. It’s about the trust of the people who handed you their details.
Is your site leaking its username?
What exposed our own problem was two addresses that handed the username to anyone who asked. It’s a good first test of your own site too. Send us the address and we’ll check it, and if you give us a login we’ll also look at your plugins and PHP version. You’ll find out what needs fixing and what can be left as it is.
Last updated: June 2026. The security landscape shifts, so individual figures and recommendations may change over time.