300 Zero-Days in 72 Hours: My Site Is 8 Days Behind

In May 2026, two security teams pointed an automated pipeline at the WordPress plugin repository and came back with more than 300 critical zero-days in 72 hours of scanning. The average cost worked out at roughly $20 per vulnerability. This week I ran wp plugin list --update=available against my own site and found eight plugins running a version behind, the oldest of them waiting since 18 August.

Those two facts belong in the same sentence, and almost nobody puts them there. The WordPress plugin zero day problem is usually discussed as a supply problem — how many holes exist, who found them, which plugin is dangerous this week. That framing is now out of date. Finding vulnerabilities has been automated and is cheap. Installing the fixes has not been automated, and on most sites it happens whenever somebody next logs in and notices the little red badge.

What the pipeline actually did

The research came from teams at TrendAI and CHT Security, presented at Ekoparty Miami and reported by Help Net Security on 22 May 2026. The pipeline was not one model reading code. It chained three stages: AI-driven static analysis to flag candidate flaws, automated Docker provisioning to stand up a disposable site for each candidate, and dynamic verification driven through Chrome DevTools MCP to prove the flaw actually fired in a browser.

The numbers attached to the run are worth reading slowly. More than 300 critical zero-days in 72 hours. Around $20 each. Roughly 222 million tokens across 95 tasks on the orchestration dashboard. Every finding was manually verified by the researchers and responsibly disclosed before publication.

Steven Yu, a threat research engineer at TrendAI, was careful to qualify the headline figure — it does not mean you can find a hole in any WordPress site for $20, it reflects the specific conditions of the plugin ecosystem. But he was blunt about the consequence: any motivated attacker with a credit card can execute this. The economics are the finding, not the count.

It is not an isolated result. On 14 August 2026 Luke Herbrandson published The Illusion of a Lock on the Sucuri blog, describing his own hands-on version of the same idea: Claude Opus 4.8 flagging suspicious patterns in plugin source, an isolated two-site lab to separate merely ugly code from genuinely exploitable flaws, and a rule that every confirmed finding had to reproduce from a clean snapshot. Dozens of plugins examined, sixteen vulnerabilities confirmed, most of them previously unreported.

His conclusion is the one that should change how a site owner thinks. AI dramatically accelerates the search phase — and that pushes the bottleneck downstream, onto verification. Machines got faster at finding. People did not get faster at confirming, patching, or installing.

The five-hour number that reframes all of this

Patchstack’s State of WordPress Security in 2026 report supplies the number that makes the asymmetry concrete: the median time to mass exploitation for vulnerabilities that actually get heavily exploited is five hours. About half of high-impact vulnerabilities are exploited within 24 hours of going public.

I have written about the volume side of that report before — the 11,334 new vulnerabilities, the 42% year-on-year rise, the 91% that live in plugins rather than core — in a post about what is sitting in your options table, which also covers the detail most write-ups get wrong about which year the dataset actually describes. I am not going to re-run those figures here. The one that matters for this argument is a different one: 46% of disclosed vulnerabilities had no fix available on the day they were disclosed.

Put the two together and you get a genuinely uncomfortable sequence. A flaw is found cheaply and quickly. In nearly half of cases it becomes public before a patch exists. Once it is public, the clock to mass exploitation is measured in hours. And then — only then — does the part that depends on you begin.

So I checked my own site

It would be dishonest to write this and not measure the thing I am describing. This site runs WordPress 7.1 with 57 plugins installed and 48 active. As of 27 August 2026, eight of them had an update available. All eight are active plugins.

Release dates come from the WordPress.org plugin API, and “full days waiting” counts complete 24-hour periods between that release timestamp and the audit. The premium Rank Math add-on is not distributed through WordPress.org, so there is no public release timestamp to measure it against — which is its own small point about how much of your update surface is even observable.

Eight days is 192 hours. The median time to mass exploitation is five. That is not a like-for-like comparison and I will say exactly why in a moment, but as an order-of-magnitude picture of where the slack in the system sits, it is hard to unsee.

What I am not claiming

This is the section that keeps the rest of the post honest, and it matters more than the charts.

None of those eight updates is known to be a security release. I did not read eight changelogs and I am not going to imply that my site has been sitting on eight open holes for a week. Most minor plugin releases are bug fixes, string changes and compatibility bumps. The honest statement is narrower and, I think, more interesting: there are eight pending updates, and the Plugins screen does not tell me which of them — if any — closes a security hole.

The five-hour median is not the clock on every disclosure. It is the median for vulnerabilities that actually went on to be mass-exploited. Most disclosed vulnerabilities never get that treatment. Comparing it directly to a routine maintenance release would be a category error.

The comparison that survives both caveats is about orders of magnitude, not arithmetic. Discovery now runs in hours for tens of dollars. Exploitation of the flaws that matter runs in hours. The interval in which a fix exists and is not yet installed runs, on a site that is actively maintained by someone who writes about this for a living, in days. That gap is structural, and it is the part a site owner actually controls.

Why the update screen is the wrong instrument

WordPress shows you a count. It does not show you a risk. Two pending updates on the Plugins screen look identical whether one of them fixes a typo in an admin notice and the other closes an unauthenticated SQL injection.

Patchstack’s data sharpens this further: 29% of the reports it handled involved premium or freemium components, and 76% of premium component vulnerabilities were exploitable in real attacks. Premium plugins are exactly the ones that do not surface in the WordPress.org update feed the way free plugins do — as my own unmeasurable Rank Math Pro row demonstrates.

There is also a supply-side cause worth naming, because the Patchstack report names it: vibe coding. Agencies generating plugins on demand, shipping LLM-written code that nobody on the team can actually audit. The same technology that made scanning cheap is making the attack surface bigger at the other end.

The eighteen-day trend on this same site

Here is the detail that convinced me this is drift rather than a bad day. On 9 August 2026 I audited this site for a post about the EU Cyber Resilience Act deadline, and recorded three plugin updates pending at the time.

Eighteen days later, that number is eight. Nothing broke and nobody made a decision — the queue simply grew, because no part of the system pushes back when it does. That is what an unmanaged update process looks like from the inside: not a failure, just a slowly lengthening line.

I have been here before in a different form. When WordPress shipped a security release earlier this year, I found that every automatic-update switch on this site said yes and the update still never installed — the dashboard reported health it could not actually deliver. The lesson from that one applies here too: the setting is not the outcome, and the only way to know is to measure the installed version.

What actually helps

• Turn on auto-updates for plugins, then verify they fired. I audited which of this site’s plugins were actually covered by an update-management service and the answer was 15 of 48. Coverage you assumed is not coverage you have. Check installed versions a week later.
• Subscribe to a vulnerability feed, not just the update badge. A feed tells you which pending update is urgent. The Plugins screen never will.
• Reduce the plugin count. The arithmetic is unforgiving: every active plugin is an independent chance that one of them, at some point, hands somebody code execution. 48 is a lot. I am aware of the irony of writing that on a site running 48.
• Treat premium plugins as a separate process. They do not ride the WordPress.org update rails, their release timestamps are often not public, and they are over-represented in exploitable vulnerabilities.
• Know what your plugins send off-site. Update lag is one exposure; outbound data is another. I counted 195 outbound call sites across the plugins on this install, which is a different audit with a similar moral.
• Publish a security contact. A /.well-known/security.txt costs nothing and gives a researcher somewhere to send a report before it becomes a disclosure.

If you run a chatbot or any AI-connected plugin, the same discipline applies to it. Our own add-ons and their update paths are listed on the add-ons page, and the documentation covers configuration in more detail.

Frequently asked questions

Does an AI finding 300 zero-days mean WordPress is insecure?

No. It means auditing is cheap now. The same pipelines are available to defenders, and the researchers in both cases disclosed responsibly. The risk is not that flaws exist — they always did — but that the discovery rate has stepped up while patch installation has not.

Should I install plugin updates immediately?

For most sites, yes, with auto-updates on and a staging copy for anything business-critical. The failure mode people fear — an update breaking the site — is real but recoverable. The failure mode on the other side is not always recoverable.

How do I tell if a pending update is a security fix?

Read the changelog, and cross-reference a vulnerability database. There is no signal in the WordPress admin itself. This is the gap the post is about.

Is “$20 per zero-day” a realistic number for any site?

No, and the researcher said so explicitly. It reflects the conditions of the WordPress plugin ecosystem specifically: a huge corpus of similar, publicly downloadable PHP with well-understood vulnerability patterns.

The short version

An automated pipeline found more than 300 WordPress plugin zero days in 72 hours at roughly $20 each. The median time to mass exploitation for the vulnerabilities that matter is five hours. My own actively maintained site had eight pending plugin updates, the oldest sitting for eight days, and the admin screen gave me no way to tell which of them mattered. The discovery side of this ecosystem has been automated. The installation side is still a human noticing a badge.