Automated Security Review for Plugin Releases  🔗 **Source:** [Automated Security Review for Plugin Releases](https://make.wordpress.org/plugins/2026/09/09/automated-security-review-for-plugin-releases/) > [!note]+ Document Notes > --- > tags: [wordpress-plugins, supply-chain-security, plugin-directory, release-engineering, ai-security-review] > author: David Perez > source: Make WordPress Plugins > reference: https://make.wordpress.org/plugins/2026/09/09/automated-security-review-for-plugin-releases/ > date created: 2026-09-10 > --- > > [!info] Generated analysis — not the author's words. Sections below are machine-written > > from the captured source. Only text inside `> [!quote]` blocks is verbatim from the author. > > Do not quote or attribute any other line to the named author. > # 🏷️ Title: Automated security review for plugin releases > ## 🧭 Table of Contents > - [📝 Summary](#-summary) > - [📖 Main Content](#-main-content) > - [🗒️ Notes](#️-notes) > - [📚 References](#-references) > - [🗣️ Paraphrase](#️-paraphrase) > - [📰 Newsletter](#-newsletter) > - [✅ Action Items](#-action-items) > - [🧪 Hypotheses](#-hypotheses) > - [📊 Methodology](#-methodology) > - [❓ Questions](#-questions) > - [🔮 Future Research](#-future-research) > - [💡 Implications](#-implications) > - [🧠 Learning Styles Assessment](#-learning-styles-assessment) > - [📊 Accessibility Assessment](#-accessibility-assessment) > - [🌍 DEIB Assessment](#-deib-assessment) > - [✅ Logical Validity](#-logical-validity) > - [🛡️ DARVO Analysis](#-darvo-analysis) > - [🎯 Conclusion](#-conclusion) > - [🔄 Refactor Appendix](#-refactor-appendix--automated-security-review-for-plugin-releases) > ### 🔗 References > - [🗒️ Notes — cooldown mechanics and the July 28 incident](#️-notes) > - [✅ Action Items — Plugins/Meta/Tide overlap](#-action-items) > - [🔄 Refactor Appendix — atoms and the permanent candidate](#-refactor-appendix--automated-security-review-for-plugin-releases) > ## 📝 Summary > - **What happened.** WordPress.org now blocks a plugin (or theme) release automatically, with no human review required, when an automated security scan assigns it a high risk score during the release's mandatory cooldown window. David Perez announced this on the Make WordPress Plugins blog on 2026-09-09. The cooldown itself isn't new — it's been running since June 5 — but automatic blocking on a high score is the new piece. > - **Why it matters.** Every plugin and theme release Courtney ships through SVN now sits behind two gates: a fixed time delay (currently 6 hours) and an AI-plus-Jetpack-Scan review that can stop distribution without anyone from the Plugins Team touching it. SVN commit success and actual user-facing distribution are no longer the same event. > - **Key stakeholders.** Plugin and theme authors distributing through the WordPress.org update API (including Courtney's post-kinds, Outpost, link-extension-for-xfn, post-formats-for-block-themes, and Social Webmention Importer); the Plugins Team, who receive block-finding emails and handle appeals; end users on one-click dashboard updates, who are the population the cooldown protects; Automattic, whose Jetpack Scan product is now one of the named scanning components. > - **Risks and tradeoffs.** The post is explicit that the score "measures risk, not intent" — an accidental vulnerability can block a release exactly as hard as a deliberate backdoor, with the same email and the same appeal path. The post gives no threshold number, no published score scale, and no stated appeal turnaround time. It also doesn't say whether the review is scoped to code changes only or to "every release" as a pipeline event — relevant given an unverified claim, sourced separately below, that a readme-only edit can itself register as a release. > - **Bottom line.** This is a concrete, narrow process change with one cited success (a July 28 backdoor caught before distribution), not a broad security overhaul. It changes release-day timing and adds a distribution dependency on Automattic tooling; both are worth planning around rather than treating as background noise. > ## 📖 Main Content > The post's core claim is narrow and mechanical: before any plugin or theme release reaches users through the WordPress.org update API — including one-click updates from the WordPress dashboard — it now sits in a cooldown window (currently 6 hours, live since June 5, per a linked companion post) during which the release diff is scanned. The scan isn't one tool; it's "several AI models together with Jetpack Scan," cross-checked against each other and combined into a single risk score. > > [!quote] > > During the cooldown, 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. > The stated purpose of cross-checking multiple tools rather than one is accuracy: > > [!quote] > > Cross-checking multiple tools keeps accuracy high and false positives low, but not zero. > What's genuinely new as of this post — not the scanning, which has existed since June, but the *consequence* of a high score — is that distribution now stops automatically: > > [!quote] > > That incident also made clear the missing piece: a high-risk result should stop distribution automatically, without depending on someone from the Plugins Team being available. > The post is careful to decouple score from motive. A high score is a risk measurement, not an accusation: > > [!quote] > > A high score does not mean malicious intent. An accidentally introduced vulnerability can score just as high as intentional malware. The score measures risk, not intent. > That framing matters for how a blocked author should react — this is not (necessarily) a finding of wrongdoing, and the post's guidance treats it that way: read the findings, fix the code, ship again. > **The incident that motivated it.** The justification offered is a single dated event: > > [!quote] > > On July 28, a backdoor was committed to a release of a plugin with around 20,000 active installations. The automated review detected it and assigned a high security score, and because the release was still inside the cooldown window, the compromised version was never distributed through the WordPress.org update API. > Read closely, this account has a seam the post doesn't flag as one: the automated review stopped the *update-API distribution*, but the plugin's page itself was reportedly closed for downloads by a person, after an external notification, not by the automated system: > > [!quote] > > The plugin was closed for downloads 26 minutes after the Plugins Team was notified by Wordfence about the update. > So two separate things happened on July 28 — the cooldown-plus-scan held back the compromised version from existing users' auto-updates (the automated part), and a human closed the plugin's listing 26 minutes after a third-party security vendor (Wordfence, not the WordPress.org scanning system) flagged it (the manual part). The post presents these as one coherent success story, and functionally the outcome was good, but the automated review is credited with a narrower win than "the incident was fully contained" — it prevented one specific distribution channel from serving the backdoored code during the cooldown, while the actual takedown still ran through a Team member and an outside notifier. > **What happens on a finding, precisely.** A blocked release stays blocked until either a new release clears the same review below threshold, or the Plugins Team resolves an appeal. The post frames appeal as the slow path: > > [!quote] > > Please understand that the team handles a high volume of reviews, so publishing a fixed release is almost always faster than waiting for a manual review of an appeal. > Notification is one-directional and silent on success: > > [!quote] > > Right now, emails are only sent when a release is blocked. Authors who haven’t received an email don’t need to take any action. > **What's left unstated.** The post does not give: a numeric threshold or score scale; which specific AI models are used, or whether that set changes over time; a false-positive rate (only the qualitative "keeps... false positives low, but not zero"); an appeal SLA; whether new-plugin submissions (already reviewed "before they enter the directory," per the post's own framing of prior process) go through this same pipeline or a separate one; and — the point most directly relevant to Courtney We’re launching an automated security review for every plugin release. Before a release is distributed through the WordPress.org update API, it is analyzed for security issues and releases that are considered to pose a potential security risk (either intentional or unintentional). This post explains how the process works and what is expected from plugin authors when a release is blocked. #### **Why we’re doing this** New plugins are reviewed before they enter the directory, but updates ship continuously after that. A plugin can be secure today and introduce a vulnerability, or malicious code, in a future release. Until now there was no consistent review step between a release being committed and that release reaching millions of sites. On July 28, a backdoor was committed to a release of a plugin with around 20,000 active installations. The automated review detected it and assigned a high security score, and because the release was still inside the cooldown window, the compromised version was never distributed through the WordPress.org update API. The plugin was closed for downloads 26 minutes after the Plugins Team was notified by Wordfence about the update. That incident also made clear the missing piece: a high-risk result should stop distribution automatically, without depending on someone from the Plugins Team being available. That’s what we’re launching now. #### **How it works** [Since June 5](https://wordpress.org/news/2026/06/pts/), every plugin and theme release goes through a cooldown before it is distributed through the WordPress.org update API, including one-click updates from the WordPress dashboard. The cooldown period is currently at 6 hours. During the cooldown, 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. The higher the score, the higher the potential risk. Cross-checking multiple tools keeps accuracy high and false positives low, but not zero. Releases with a high risk score are blocked automatically as soon as the security review finishes, and all plugin committers receive an email with the findings. Releases below that threshold continue through the normal process. A high score does not mean malicious intent. An accidentally introduced vulnerability can score just as high as intentional malware. The score measures risk, not intent. Right now, emails are only sent when a release is blocked. Authors who haven’t received an email don’t need to take any action. #### **When a release is blocked** A high risk score means the release will not be distributed through the update API until the issues are resolved. The fastest way to get a release unblocked: 1. **Review the reported findings.** They describe what triggered the block. 2. **Fix the issues and publish a new release.** When the new release scores below the blocking threshold, it continues through the normal cooldown process. 3. **If a finding looks incorrect**, authors can contact the Plugins Team. Please understand that the team handles a high volume of reviews, so publishing a fixed release is almost always faster than waiting for a manual review of an appeal. #### **Feedback** This process will keep evolving as we collect more data and improve the checks. Feedback about false positives is the most useful thing plugin authors can give us to make the system better., Automated Security Review for Plugin Releases, David Perez, 01m25kjbfermyf2v9qtnpkxpjp.