For years, WordPress has been the sensible default for a business website. Pick a theme, add a few plugins, sort out hosting, done. I have built plenty of them myself, and for a lot of businesses it was the right call.
I don't think it is the right call any more, at least not the way most sites get built. Not because WordPress has suddenly got worse, but because the people looking for holes in software have had their job made a lot easier this year, and WordPress is the biggest target on the internet.
I want to lay out the numbers, because this is one of those arguments that sounds like fear-mongering until you see them.
What changed in 2026
Finding a security flaw in software used to take real skill and real time. Someone had to read the code, understand it, work out where the author made a wrong assumption, and then prove it could be abused. That skill still matters, but AI has taken a lot of the hours out of it.
In April, Anthropic started Project Glasswing, pointing its Mythos model at open source software. By May it had scanned more than 1,000 projects and flagged 23,019 issues, 6,202 of them rated high or critical. When outside security firms checked a sample of those, more than 90 per cent were real. The maintainers of some of that software asked Anthropic to slow down, because they could not write fixes as fast as the bugs were arriving. By early October, 6,157 vulnerabilities had been reported to 591 projects, and 516 had been patched.
Those are Anthropic's own figures and they come with the usual caveats about a company talking up its product. But Google's Threat Intelligence Group, which has no reason to talk up a rival's model, published its own analysis on 1 October. The number of vulnerabilities disclosed each month went from 5,045 in January to 10,477 in July. The number actually being exploited in the wild went up too: 141 in the first eight months of 2026, against 127 for the whole of 2025.
Google is careful not to pin all of that on AI. Some of it is vendors changing how they report. But the trend it does call out is the one that matters for a business website: most of the growth in attacks is not new, secret zero-days. It is known, already-patched bugs being turned into working exploits faster than before, because comparing a patched version against an unpatched one is exactly the kind of job a language model is good at.
So the window between "a fix was released" and "someone is attacking your site with it" is shrinking. That window is the whole game.
Why WordPress wears most of this
WordPress runs about 40 per cent of all websites. If you are an attacker with a working exploit, that is where you point it, because one bug gets you into the most sites.
And the attack surface is not WordPress itself. It is everything bolted onto it. Patchstack's annual report counted 11,334 new vulnerabilities in the WordPress ecosystem in 2025, up 42 per cent on the year before. Of those, 91 per cent were in plugins and 9 per cent in themes. WordPress core accounted for six, all low priority.
Two more numbers from that report stuck with me. Nearly half of those vulnerabilities, 46 per cent, had no fix available from the developer when they were made public. And for the bugs attackers cared about, the median time from disclosure to mass exploitation was five hours.
Five hours. Most small business sites I see get their plugins updated when somebody remembers, which is somewhere between monthly and never.
Here is what that looks like in practice, all from this year:
- Gravity SMTP, an email plugin on about 100,000 sites, had a bug that let anyone on the internet pull the site's configuration, including the API keys and OAuth tokens for its email accounts. It was rated medium severity, low enough that Wordfence did not initially bother writing a firewall rule for it. Wordfence has since blocked more than 17 million attempts to exploit it.
- BdThemes, a vendor whose Element Pack plugin has more than 100,000 installs, had its plugins compromised in August without a single file changing on WordPress.org. Attackers got into the storage behind a promotional banner the plugins fetch, and used it to create admin accounts on sites whose owner simply opened their dashboard. WordPress.org pulled the plugins from its directory while it investigated.
- WordPress core itself had its first critical unauthenticated remote code execution bug in nearly a decade in July. The patch came out on a Friday. Wordfence saw the first exploit attempts that same evening, and working exploit code was circulating over the weekend.
None of these attacks needed to know who you are. Nobody targeted a Hobart plumber or a Launceston accountant. A scanner found a version number, and that was enough.
This was always the deal, it just got worse
A typical small business WordPress site I get asked to look at has a commercial theme, a page builder, and somewhere between 15 and 40 plugins. Each one is written and maintained by a different person or company. Some are a single developer who has moved on. Each one is a door, and you are trusting every one of those people to keep their door locked, forever, for free.
That was a tolerable bet when finding a way through a door took weeks of expert effort. It is a much worse bet when the finding is automated and the exploiting starts within hours.
The honest answer is not "WordPress is insecure". Core is maintained by serious people. The honest answer is that a WordPress site is a bundle of 20 or 30 separate pieces of software, and keeping that bundle safe is now a job that has to be done every week, by someone who is actually watching.
Get off it
My advice, if you run a business website on WordPress, is to stop. Not patch harder, not add another security plugin to the pile. Move to something that does not have 30 doors to guard.
What you move to depends on what your site actually does, and for most businesses it is one of two things.
If your site is a brochure, go static. A lot of business websites are a handful of pages, a contact form and a blog that gets updated a few times a year. That does not need a database, a login page or a plugin ecosystem. A static site is built once into plain files and served from a global network. There is no admin panel for anyone to break into and no server-side code for a scanner to probe. The Gravity SMTP bug, the BdThemes compromise and wp2shell all needed something running on the server. A static site has nothing running. It is also faster, cheaper to host, and the kind of thing that can sit untouched for a year without becoming a liability.
If you really do edit content often, use a modern CMS. Some businesses genuinely need an editor: a team publishing weekly, a catalogue, a members area. For that I would use something like Payload, a CMS built in the last few years rather than the last twenty. The difference is structural. The content editing lives behind proper authentication with the rest of the application, the site itself is still delivered as pre-built pages, and there is no marketplace of third-party plugins fetching things from other people's servers. You add a feature by writing it into the codebase, where it gets reviewed and versioned like everything else, not by installing a stranger's zip file.
Either way, the point is the same: a site with fewer moving parts has fewer things to go wrong, and the parts that remain are ones you control.
We can move you
This is work we do. We take an existing WordPress site, keep the content, the design and the URLs that Google already knows about, and rebuild it as either a static site or a Payload site depending on what you need. The redirects are set up so nothing you have earned in search is lost, the forms keep working, and the plugin bundle goes in the bin.
If your site is on WordPress and you have not looked at the plugin list in a while, that is probably reason enough to talk. Tell us what you have and we will tell you straight which of the two options fits and what it would take.