We looked at the data: what WordPress.org’s 24-hour update delay means for vulnerabilities and supply-chain attacks.
WordPress.org’s new update-review policy – Protect the Shire – is doing exactly what it was built to do – for one kind of threat. For another, it’s quietly making things worse.
Here’s the case for both, with the data behind each.
How Protect The Shire actually works
On June 5th, 2026, WordPress.org announced Protect The Shire, an initiative to lock down the roughly 78,000 plugins and themes in the WordPress.org directory. Its first concrete measure: every new plugin and theme release now waits before it’s served through the update mechanism – auto-update and the manual “Update Now” button both, since they’re gated by the same clock.
We didn’t take WordPress.org’s account of how long that hold lasts, or when it changed – we measured it directly.
Daily median gate times held steady at roughly 24.2-24.5 hours from July 7 through July 15, then stepped sharply to roughly 6.6-6.8 hours starting July 16 – a single-day change, no gradual ramp, visible across hundreds of releases a day.
The security reasoning behind the hold is fair on its face: plugins have been sold to new owners who quietly plant backdoors, and AI-assisted development is making it easier to slip bad code into a release unnoticed. A pause before a release reaches every site is a real, sensible response to that risk. It’s also not a new idea – similar review windows before automatic distribution have been part of the conversation in other software ecosystems for a while now, as supply-chain attacks have become more common there too.
The question worth asking isn’t whether that instinct is reasonable. It’s:
Does one hold, applied to every release, perform equally well against two very different threats?
Where it works: supply chain attacks
On July 28th, Wordfence caught a planted backdoor in Advanced Responsive Video Embedder (20,000 installs) two hours after the malicious code landed. CVE-2026-18072, CVSS 9.8, full admin takeover via one request. WordPress.org pulled it the same day, and it was not yet broadly distributed via auto-update.
Two hours of detection sitting inside a six-hour hold – it’s the exact scenario the policy is built for. We can’t prove the hold caused the save; WordPress.org may have just pulled it fast once notified. But it’s consistent with the mechanism doing its job, and it matches how other ecosystems already handle this exact risk with pre-distribution review windows.
Placed in the right context, the ARVE case involved roughly 20,000 installs. It’s the one well-documented case we can point to right now; if there are other confirmed supply-chain saves, we’d want to name them too, since one case is a data point, not a pattern. Set that number against the other side of this piece: 79 plugins, ~9.9 million combined installs, sitting through the same kind of gate without a patch.
Even taken as a clean win, the blast radius Protect The Shire demonstrably reduced is a rounding error compared to the exposure it’s currently creating.
Where Protect the Shire doesn’t work: disclosed vulnerabilities
Malicious releases and disclosed vulnerabilities are different problems. Protect The Shire treats them identically. That’s the issue.
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.
We specifically checked whether disclosed security fixes got any different treatment than routine releases – 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 fixing a critical vulnerability waits the same line as a plugin changing a button color.
Over that 17-day window, 81 releases patching a disclosed CVE moved 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. (We want to be precise here: “Combined install base” describes install counts across those plugins, not confirmed vulnerable sites – we can’t tell how many individual installs were still running the unpatched version, and a manual reinstall bypasses the delay entirely.)
Two concrete examples show what this actually looks like:
- AcyMailing’s plugin page and its plugin_information API (the data behind the “View details” popup) both showed version 10.11.1 – the fix for an unauthenticated SQL injection – while its update-check API was still serving 10.11.0, the vulnerable version.
2. The Page View Count plugin did the same: 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, contact-form-7-mailchimp-extension, tracked under CVE-2026-15000 (a publicly logged, stored XSS vulnerability), measured at 24.5 hours gated – in line with everything else.
We specifically checked for evidence of active exploitation happening during any of these gate windows, from July 7 to now, and found none. Worth flagging the inverse too – the one vulnerability we did see under active exploitation during this period wasn’t caught by the delay at all; its fix was already auto-updatable since it was a Core vulnerability.
We also spotted a case where update-check served an older version while a fresh reinstall grabbed the newer one with zero fuss. One instance isn’t proof it works every time, but it’s worth testing on your own setup rather than taking our word for it – since it’s currently the one move that reliably works: deleting a plugin and reinstalling it fresh, or grabbing the zip directly, skips the wait entirely.
Nobody does that to a plugin their dashboard insists is already current. Why would they?
The speed gap
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. But 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.
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
Protect The Shire does well against supply chain attacks. But against disclosed vulnerabilities, one clock is doing two jobs and only winning one. Exempt confirmed vulnerability fixes from the hold, or fast-track them through the same review process WordPress.org has said could shrink toward minutes. Right now it doesn’t distinguish between the two, and that’s the fixable part.
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.
