Ask a small business owner when their website was last updated and you will usually get one of two answers. Either they do not know, or somebody clicked “update all” a few months ago and nothing broke, so it has not been touched since.
The trouble is that the risk does not arrive on a monthly schedule. It arrives the day a flaw is published.
What 2025 looked like
Patchstack runs a vulnerability database for WordPress, the platform behind a large share of small business sites. They sell security services, so read their numbers knowing that, but the figures are drawn from their own disclosure data. (Patchstack, State of WordPress Security in 2026, 25 February 2026)
They recorded 11,334 new vulnerabilities in the WordPress ecosystem in 2025, 42% more than in 2024.
Of those, 91% were in plugins and 9% in themes. WordPress itself had six. If you picture the risk as “WordPress”, you are looking in the wrong place. It sits in the add-ons, and most sites have more of those than anyone remembers installing.
Nearly half, 46%, were not fixed by the developer in time for public disclosure. For those, updating promptly does nothing, because there is no update to apply.
For the vulnerabilities attackers went after hardest, Patchstack puts the weighted median time to first exploit at five hours after disclosure.
And in their testing, the defences a typical hosting company provides blocked 26% of attacks.
What that means in practice
Put those together and a monthly update routine looks thin. A flaw can be published and exploited in the time between breakfast and lunch. Nearly half the time there is no patch yet. The host’s firewall stops about one attack in four.
When it goes wrong, the bill is rarely just the clean-up. Somebody has to work out what was changed and when. Search engines may flag the site as unsafe, and that warning can outlast the fix. Enquiries stop quietly, and if the site was sending spam or skimming a form, you may have a privacy problem as well as a technical one. None of that shows up on an invoice labelled “updates”.
What to ask whoever looks after your site
You do not need to become a security expert. You do need answers to a few plain questions.
Who applies updates, and how soon after a security release? “Once a month” is an answer, but it is not a good one for a site carrying plugins.
What happens when a vulnerability has no fix? Somebody should be able to say whether the plugin gets disabled, replaced or protected some other way, and who makes that call.
How many plugins does the site run, and does it need all of them? Every one is a separate supplier whose mistakes become yours. The cheapest update is the one for a plugin you removed.
Are updates tested before they reach the live site? An update that breaks your contact form is its own kind of outage.
Is anyone watching the site between updates? Monitoring that tells you the site changed, went down or started sending mail it should not is what turns five hours into something you hear about the same day.
Part of the reason I build the way I do is to shrink that list. A site with fewer moving parts has less to patch and fewer places to be caught out. But whatever your site is built on, the questions are the same, and the answers should be written down somewhere other than one person’s memory.
