WordPress.org Now Holds Every Plugin Release for Six Hours. Here Is What That Buys You.

On 28 July 2026 someone committed a backdoor to a WordPress.org plugin with around twenty thousand active installs. Twenty-six minutes after the Plugins Team was notified, the release was pulled. Nobody auto-updated to it. Six months earlier that release would have been on every one of those sites by the following morning, and the first anyone would have known about it is when the spam links started showing up in Google.

The difference is an initiative WordPress.org launched in June under the name "Protect The Shire". It has two parts, one of which most people have heard of and one of which most people have not, and it is worth understanding both properly, because it changes what your own update process needs to do and what it can stop doing.

Part one: the cooldown

Since 5 June 2026, every plugin and theme release across the WordPress.org directory sits in a holding period before sites running auto-updates receive it. It launched at 24 hours. On 18 July it was cut to six, announced by Konstantin Obenland in the WordPress Slack as "a first iteration", with a further reduction planned for releases that the automated review clears cleanly.

The cut caught developers by surprise. Yoast's lead developer pointed out on the day that plugin teams plan release schedules and shifts around the delay and would have liked notice. That is a fair complaint about communication. It does not change the substance. Six hours is the number to plan around today, and it will probably get smaller.

What the cooldown does is simple. It converts the gap between "release published" and "release on your site" from zero into a window in which somebody can look. Before June, a compromised release from a trusted publisher reached auto-updating sites at exactly the same speed as a legitimate one. There was no point at which anybody could intervene. Now there is.

Part two: the automated review

This is the part that does the looking, and it is the more important half.

During the cooldown, every release is analysed by several AI models together with Jetpack Scan. The results are cross-checked and combined into a security score. Until 9 September a bad score got a human's attention. Since 9 September a high-risk score blocks the release outright: it is not distributed through the update API until the issues are resolved, and every committer on the plugin gets an email with the findings. If an author thinks a finding is wrong they can appeal to the Plugins Team, though WordPress.org's own advice is that shipping a fixed release is almost always faster than waiting for an appeal to be reviewed.

The 28 July incident is what this looks like in practice. A backdoor was committed. The review flagged it in the cooldown window. Within 26 minutes of the Plugins Team being told, the release was gone. Twenty thousand sites never saw it.

Put those two parts together and the thing that made April's Essential Plugin incident work, a trusted publisher shipping a poisoned release straight into auto-updates, now has a filter in front of it. That is a real improvement to the ecosystem, and I want to say that plainly before getting to the caveats, because the caveats are where the useful advice is.

What the review cannot see

The review reads the diff of a release. That is what it can do, and it does it well enough to catch a backdoor. There are two things a diff scan cannot know.

It does not know who the maintainer is. The Essential Plugin attacker bought thirty plugins on Flippa, ran clean updates for eight months, and only then shipped the payload. A diff scan would have passed every one of those eight months of releases, because they were clean. The trust-building phase of an ownership-transfer attack produces nothing for a scanner to find. Whether it would have caught the final release is a fair question, and the July incident suggests it might. But the eight months before it were invisible by design, and the only signal that existed during that time was "this plugin changed hands", which WordPress.org still does not surface.

It does not know whether a clean-looking change is step one of something longer. A release that adds a remote configuration fetch, on its own, is not malicious. A release six weeks later that changes what the fetch does is where the damage is. Each diff in isolation can look reasonable. The pattern only exists across releases and across time, and that is not what a per-release review is built to see.

So the review is a good filter for the crude cases and no substitute for knowing what is installed on your sites and who publishes it.

The trade-off nobody has resolved

Patchstack raised this at launch and it still applies, just with a smaller number.

Patchstack's 2026 report counted 11,334 new vulnerabilities across the WordPress ecosystem in 2025, up 42% on the year before. Among the most heavily targeted of those, the median time from public disclosure to first exploitation was five hours. Around half of the high-impact ones were being exploited within a day.

Now put a six-hour hold on every release. For a plugin with a vulnerability that is already being exploited, the fix is ready, the developer has shipped it, and it sits in the cooldown for six hours while the attackers, who have had the details since disclosure, keep going. The hold that slows a supply-chain attack is the same hold that delays a legitimate security patch, and five hours is right on top of six.

This is why the planned next step, skipping the cooldown for releases the review clears, matters more than the current number. Until it lands, the practical rule is the one in the handbook: for a plugin with an actively exploited vulnerability on a site that matters, apply the verified security release by hand rather than wait for the cooldown to release it. For everything else, the six hours is doing you a favour.

What this changes for you

Less than you might hope, and in a direction that should be comfortable.

• Keep auto-updates on for the narrow, low-footprint plugins. The cooldown and review make that a safer default than it was in May. The failure mode auto-updates fix, an unpatched CVE nobody got round to, is still far more common than a poisoned release.
• Keep the observation window for the wide-reach ones. WooCommerce, page builders, security and backup plugins, anything with deep hooks into your site. WordPress.org's six hours is a floor, not a replacement for your own day or two of watching the support forum after a big release.
• Keep the inventory. The review cannot tell you a plugin changed hands. Your list of what is installed and who publishes it is still the only thing that can.
• Treat a blocked release as information. If a plugin you run goes quiet for a release cycle, or its changelog mentions "addressing review findings", that is worth a look before you update.

The ecosystem has moved a meaningful step towards catching the crude supply-chain cases at the source. What it has not done, and cannot do from a diff, is replace your own knowledge of what is running on your sites. That part is still yours.

Where this fits

Chapter 8 of the Protect My WP handbook covers plugin and theme hygiene end to end: how to vet a plugin before you install it, the tiered update policy that decides which plugins auto-update and which get watched, the ownership-transfer risk that install counts hide, and the file-level places where a compromised release leaves persistence behind. It was updated this week for the six-hour cooldown and the automated review, with the Patchstack figures above alongside them.

Get the book for £19.