What WordPress.org’s 24-hour update delay actually cost the ecosystem, and why 6 hours isn’t better.
If your WordPress dashboard says a plugin is up to date, you believe it. Or, you used to.
That was the practical effect of Protect The Shire, WordPress.org’s initiative to lock down roughly 78,000 plugins and themes living in the WordPress.org directory. It was rolled out on June 5th, 2026, with a mandatory 24-hour hold before releases reached sites.
That hold has since been shortened to roughly 6 hours on July 16th.
This is a look back at what those first six weeks, under the original 24-hour window, actually meant. Today, a shorter wait is a real improvement, but it isn’t the same as solved.
The rest of this piece covers what we measured under the 24-hour window – but the core mechanism, and the risk, are still live at 6.
Why the update didn’t really protect the Shire
First policy move: every new plugin and theme release waited up to 24 hours before it showed up as available in your dashboard.
The security concerns behind it are fair (plugins getting sold to owners who slip backdoors into them, bad code produced by AI, etc.), but here’s where it gets messy:
Firstly, the announcement called this a hold on auto-updates. When we tested it ourselves, we found that wasn’t the whole story: auto-update and the manual button are gated by the same clock.
Secondly, the hold treats routine feature bumps and fixes for live vulnerabilities the same way. In practice, this means attackers can find out about a vulnerability before you can get the update fixing it.
What we saw across 114 releases
During June and the first part of July, we tracked three things in parallel for every release:
- When a version gets tagged, i.e., a plugin developer marks it as ready
- When it’s downloadable,
- When the update-check API actually starts serving it in your WP admin dashboard
Tag-to-downloadable is basically instant. The 24-hour (and now 6-hour) delay is in that last step.
Across 114 resolved releases, plugin and theme updates were held back by a median gate of 24.4 hours.
In that same window, our monitoring logged 104 cases where WordPress.org’s own cooldown timer was the holdup, and zero cases where a developer was just slow to ship. Nothing was slow to become downloadable – everything was slow to become updatable.
We checked whether security fixes got any special treatment – faster clearance, given the stakes. They didn’t. Splitting confirmed security releases (fixes matching a disclosed CVE) from routine ones by date shows both held for almost exactly the same duration in each era: about 24.4 hours before July 16, about 6.8 hours after.
A plugin patching a critical vulnerability waits the same line as a plugin changing a button color.
A developer would have needed to specifically request an exception from the WordPress plugin team to skip the 24-hour hold, which only adds to the confusion in the ecosystem.
Security releases are constant, and this problem repeats across our dataset.
Over a 17-day window, we tracked 81 releases patching a disclosed CVE moving through this delay – 49 under the old 24-hour window, 32 under the new 6-hour one – spanning 79 distinct plugins with a combined install base of roughly 9.9 million.
Thirty of those fixes were rated CVSS 7.0 or higher; nine were rated 9.0 or higher, including one perfect 10.0, an arbitrary file deletion vulnerability.
Two examples make the pattern concrete:
1. AcyMailing’s plugin page and its plugin_information API (the data behind the ‘View details’ popup) both showed 10.11.1 – the fix for an unauthenticated SQL injection – while its update-check API (the one that actually tells your site there’s something to install) was still handing out 10.11.0, the vulnerable version.
2. The Page View Count plugin did the same dance: plugin page and metadata API at 2.9.2, update-check stuck on 2.9.1, the version with a lower-privilege settings-change bug.
A third case appeared in our wider dataset: contact-form-7-mailchimp-extension, tracked under CVE-2026-15000 (stored XSS), measured at 24.5 hours gated.
We also spotted a case where update-check served an older version while a fresh reinstall grabbed the newer one with zero fuss – which lines up with the workaround below.
Why this is a problem
Before, you could trust your WP admin dashboard when it told you whether or not a plugin had an update. You could act on it. It was always a flawed protection mechanism because the median time to mass exploitation for heavily exploited vulnerabilities is 5 hours.
That’s the average. Here’s what it looked like in a specific case: for a critical WordPress core vulnerability we disclosed in July, we recorded real exploitation attempts starting 90 minutes after the patched version was released – three hours after the fix was even committed. Core updates aren’t gated by Protect The Shire the way plugin updates are, but the lesson transfers: once a fix is public, attackers don’t need hours. They need minutes.
So, shrinking The Shire window to 6 hours didn’t change much. If mass exploitation typically starts within 5 hours of a vulnerability becoming known, a 6-hour delay still leaves room for an attacker to move before your dashboard shows anything’s wrong. Better than 24 hours, but not the same as safe.
And with the Shire update, the new version becomes downloadable almost the instant a developer ships it, but the update-check API blocks it from becoming available to you.
At the same time, the updated code and its existence become public.
Attackers monitoring changelogs can see the fix and target the issue on a site whose owner isn’t even aware there is a problem, since there is no plugin update.
This means a site owner doing everything right – actually checking the dashboard, seeing nothing pending, moving on with their day – isn’t necessarily safe.
The one move that does work is deleting the plugin and reinstalling it fresh, or grabbing the zip directly. But nobody does that to a plugin their dashboard insists is already up to date. Why would they?
The problem scales with agencies and hosts
This gap doesn’t stop at the person clicking “Update Now.” Agencies and hosts managing sites at scale lean on tools specifically to catch vulnerabilities and trigger updates fast – often faster than any individual site owner could manage on their own.
These tools sit on top of the same update mechanism WordPress.org just gated. If the layer underneath is blind to a fix for 6 hours, the tool built to move faster than that is blind too. Speed built on top of a slow foundation is still slow.
That’s a bigger problem than one unpatched site. It’s every site under that tooling, all exposed the same way, at the same time.
And if you’re a host, this is your fleet, not just one customer’s site – a 6-hour blind spot on your infrastructure is a 6-hour blind spot on every account running the affected plugin.
What you can do right now
If you manage sites at scale, don’t assume your update tooling closes this gap just because it’s faster than a manual check – it’s likely built on the same API that’s currently the bottleneck.
Since Patchstack tracks vulnerabilities and updates independently, we’re now offering hosting partners a straightforward option: give your customers free protection for 30 days, at our cost, so vulnerabilities get covered the moment they’re detected – not whenever WordPress.org’s update-check catches up.
A head start shouldn’t belong to the attacker. For six weeks, it was a full day long. It’s six hours now – an improvement, but still longer than attackers typically need to start exploiting a known, public fix.
And shorter isn’t the same as solved.
For immediate protection, contact us.
