WordPress.org Now Auto-Blocks Risky Plugin Releases

When a plugin author tags a release on WordPress.org, the update no longer goes straight out. It sits. Since 5 June 2026 every plugin and theme release passes through a six-hour cooldown before it becomes available through the update API, and an announcement dated 9 September 2026 on automated security review for plugin releases changed what happens at the end of that window.

What happens in those six hours

The Plugins Team describes the pipeline directly: “the changes in each release are analyzed in WordPress.org by several AI models together with Jetpack Scan. The results are cross-checked and combined into findings with a security score.”

Two details are worth separating out. The analysis runs on the diff, not the whole plugin, so it is looking at what changed in this release rather than re-auditing a codebase. And the output is a score, not a verdict — the announcement says plainly that a high score does not mean malicious intent. Obfuscated code, a new remote request, a changed capability check and a genuine refactor can all raise it.

The six hours exist because a malicious release is only useful to an attacker while it is being distributed. A window between tagging and distribution converts a supply-chain compromise from something that reaches sites automatically into something that has to survive review first.

What changed on 9 September

Before that date, a high-risk finding sent an email and waited for a person. The release still went out when the cooldown expired. Since the announcement, a release that scores high enough is blocked automatically as soon as the review finishes, with no human in the loop.

That is a deliberate trade. Automatic blocking means false positives now stop legitimate releases, and a plugin author shipping an urgent fix can find it held by a classifier. The team accepted that cost because the alternative — a real backdoor distributing for hours while an email waits in a queue — is the worse failure. For anyone who ships a plugin, the practical consequence is that a security release should be tagged with the cooldown budgeted in, not assumed to reach sites immediately.

The case it has already caught

The announcement gives one worked example. On 28 July 2026, a backdoor was inserted into a release of a plugin with around 20,000 active installations. The automated review scored it high, and because the release was still inside the cooldown window the compromised version was never distributed. The plugin was closed for downloads 26 minutes after the Plugins Team was notified.

The number that matters there is not 26 minutes. It is that the compromised build never reached a single site, which is the difference between an incident report and a cleanup operation. Under the previous arrangement, 20,000 installs would have had a window in which to auto-update into it.

What it does not protect you from

The limits are specific, and treating this as general coverage would be a mistake.

• It reviews releases, not the backlog. A vulnerability that has sat in a plugin for three years is not a change, so the diff analysis has nothing to look at. Existing flaws are unaffected.
• It only covers plugins distributed through WordPress.org. Premium plugins that update from a vendor’s own licence server never enter the pipeline. On a typical commercial site, those are the plugins with the most privileged code.
• It is a score, not a proof. A clean review means nothing suspicious was detected in a diff by automated analysis, which is not the same as the release being safe.
• It does not cover themes and plugins installed by upload, which is how most nulled and abandoned code arrives.

How this should change your plugin policy

The old advice to wait a week before applying plugin updates was always a rough instrument, and it is now a worse one. Six hours of automated review happens whether you wait or not, and the residual risk after that window is dominated by flaws the review cannot see. Delaying an update leaves you on a version whose vulnerabilities are public rather than hypothetical, which is the trade covered in what to actually check before you install a plugin.

Update promptly, keep a restorable backup, and spend the saved attention on the part of the stack this does not reach. That means an inventory of every plugin that updates from outside WordPress.org, with a named owner and a way to find out when that vendor ships a security fix. It also means treating install counts as a popularity measure rather than an assurance: a plugin with 100,000 installs has had more eyes on it and is a more valuable target, and those two facts do not cancel out. The automated security review documentation for plugin authors sets out what the pipeline checks, which is also the most useful reading for anyone evaluating a plugin rather than shipping one. The broader exposure on a typical install — REST API security and the accumulated cruft behind why large WordPress sites slow down — is where deactivated-but-installed plugins keep costing you.