The bit nobody mentions
When people picture a website being hacked they picture something happening. A defaced homepage. An error. Something obviously wrong.
That is not what this looked like. They got in during July and did nothing at all for three weeks. No defacement, no errors, nothing that would prompt anyone to look. The spam only started publishing in August.
The silence is the design. It is how these campaigns avoid being noticed, and it is why “patch quickly and you are fine” turned out to be incomplete advice.
What actually happened
In July a critical flaw was disclosed in WordPress itself — not a plugin, not a theme, not somebody’s bad configuration. Core. It was rated 9.8 out of 10 for severity, which is effectively the top of the scale, and on the day it was disclosed roughly one in four WordPress installations were exposed.
WordPress powers about 40% of the web, so the numbers get silly quickly. Credible estimates put up to 500 million websites at risk. Not hacked — at risk. The distinction matters and most of the coverage got it wrong.
Ninety minutes
Here is the part that changed how we think about this.
The flaw was found by researchers using an AI model. Within roughly ninety minutes of it being made public, a working attack was circulating — and at least one security firm reported rebuilding a working exploit in minutes using frontier AI models. Their phrase for it was that once the flaw was public, rebuilding it was a matter of time and tokens.
AI found it. AI weaponised it. That is not us being dramatic; it is documented, and it is why this moved faster than anything comparable before it.
Now hold that against the other number. A live website typically receives an update within twenty-four to seventy-two hours. That is not slow. That is normal, sensible practice.
Ninety minutes against seventy-two hours. That gap is the entire story, and nothing you do inside a website closes it.
What we found going through them by hand
We look after a lot of WordPress sites. When this landed we opened every one of them — not a scan, actually reading the files, one at a time. It took two weeks.
Four things we found that almost nobody is writing about:
The patch closed the door and left them inside
Sites updated, many automatically. The flaw was fixed. They were still compromised — because a patch removes a vulnerability, it does not remove what somebody already planted. Closing the door does not help if they have already left a key under the mat.
Scanners could not see most of it
Some of what we found was not code at all. A copy of a site’s configuration saved as a plain text file, sitting in a public folder, readable by anyone who knew the address — and invisible to every malware scanner, because it is not a program. Other payloads lived in the database rather than in any file. No file scan finds those, and a files-only restore brings them straight back.
No new admin account was ever created
With the database credentials, an attacker does not need to add an administrator. They can rewrite an existing one — change the password, change the email address so password resets come to them. Nothing appears in the users list as new. Every “check for unfamiliar admin accounts” instruction on the internet misses it. The email address is the tell, not the username.
One file was writing all the others
This was the most useful thing we learned. On sites that appeared to reinfect after being cleaned, a single planted file was regenerating fresh malicious files on every page load. Remove the visible ones and it simply wrote new ones for the next visitor. It was not a backdoor, it was a factory.
What the spam was actually for
Gambling content, published in six languages, none of it visible on the homepage and none of it something a visitor would notice. The aim was never defacement — it was search visibility. It is designed to sit quietly while Google indexes it.
Which is the other reason nobody spotted it for three weeks.
So what actually closes the gap
Three things, and only one of them happens inside the website.
Something in front of the site. A firewall that filters attacks before they reach the server, with threat rules updated in real time. Free security plugins typically run their rules about a month behind the paid versions. Against something weaponised in ninety minutes, a month is not a delay — it is the whole problem.
Speed on critical releases. Not the next scheduled maintenance window. Within twenty-four hours, separately from everything else. When a major plugin advisory landed on a Friday morning this month, every site on our watch list was updated the same morning.
Somebody actually looking. Automated scanning that nobody reads is a log file, not protection. The value is not the alert. It is a person who knows what normal looks like for your site.
And a harder question
For some websites the honest answer is not more protection. It is fewer moving parts.
A static site has no database, no plugins and no login page. There is nothing to break into — not well defended, genuinely nothing there. This flaw would have had no way in, because there is no way in. We rebuilt our own site that way this year.
It does not suit everyone and we will say so if it does not suit you. A site whose team publishes weekly, runs a shop or takes bookings needs a content management system. The question worth asking is not whether everything should be static. It is whether WordPress is still the right foundation for your site, or just what somebody chose five years ago.
What we are not going to tell you
That this cannot happen again. In the week after this incident, two further advisories were issued for two of the most widely used WordPress plugins in existence. That is the environment now, and anyone promising you immunity is going to be made a liar by the next announcement.
What we would rather be judged on is what happens when something does go wrong: that you find us already working on it.
The thing that caught well-maintained websites this summer was not negligence. It was ninety minutes against seventy-two hours. Closing that gap needs something in front of the site, not just diligence behind it.
Here is what we now do as standard, and what the plans cover →