Published on gastropod.io on 09-17-2026

WordPress.org Now Blocks High-Risk Plugin Releases Automatically During a Six-Hour Cooldown

Tags: software-supply-chain-security, vulnerability-intelligence, wordpress, plugins, release-cooldown, registry-security

WordPress.org now runs an automated security review on every plugin release before the WordPress.org update API distributes it, and it blocks releases that score as high risk. David Perez, co-lead of the Plugins Team, announced the change on September 9 (Make WordPress Plugins). New plugins already went through review before entering the directory, but updates to approved plugins reached sites with no consistent check between the commit and distribution.

The review runs inside a cooldown WordPress.org introduced on June 5. Every plugin and theme release is held for six hours before the update API distributes it, including one-click updates from the WordPress dashboard. During that hold, several AI models and Jetpack Scan analyze the changes in the release. WordPress.org cross-checks the results and combines them into a security score. Releases above the blocking threshold stay blocked until the author publishes a fixed release, and everyone with commit access to the plugin receives an email describing the findings. The score covers accidental vulnerabilities as well as malicious code, so a block does not indicate intent (The Hacker News).

A July 28 incident prompted the automatic block. Someone committed a backdoor to a release of a plugin with about 20,000 active installations. The automated review gave it a high score, and because the release was still inside the cooldown, the update API never distributed it. The Plugins Team closed the plugin for downloads 26 minutes after Wordfence reported it. Before this change, stopping distribution depended on a Plugins Team member being available to act; the review now blocks the release itself (Help Net Security). Perez said WordPress.org may shorten the cooldown if the system runs without problems.

Package registries have adopted similar holds this year. GitHub's Dependabot waits three days after a release before opening an update pull request, and PyPI rejects new file uploads to releases older than 14 days (SecurityWeek). A hold protects consumers only when two conditions are met: someone detects the problem inside the window, and consumers do not bypass the hold. A plugin that force-installs updates directly from the WordPress.org API and skips the cooldown was already published on GitHub. Any site that uses it gives up the protection.

A registry-side hold also does nothing for releases that pass review and turn out to be malicious later. A compromised release can clear a six-hour window, the same as the keyv worm releases that had no matching commit, which I have already covered here: https://gastropod.io/news/the-keyv-worm-published-releases-that-had-no-commit-behind-them. Once a release is distributed, the questions move to the consumer: which machines installed it, and how do we stop it from being installed again.

Sources: