WordPress.org Plugin Release Cooldown and Security Review ![rw-book-cover](https://attowp.com/wp-content/uploads/2026/09/at-cooldown.webp) 🔗 **Source:** [WordPress.org Plugin Release Cooldown and Security Review](https://attowp.com/wordpress-development/wordpress-org-plugin-release-cooldown-security-review/) > [!note]+ Document Notes > tags: [plugin-security, supply-chain-security, wordpress-plugin-directory, release-engineering, coordinated-disclosure, automated-code-review] > author: attowp.com > source: AttoWP > reference: https://attowp.com/wordpress-development/wordpress-org-plugin-release-cooldown-security-review/ > date created: 2026-09-19 18:03 > > > [!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: WordPress.org Plugin Release Cooldown and Security Review > <!-- deep-read:sections start --> ## 🧭 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) ### 🔗 References - The capture carries 10 external citation link(s); the substantive ones: - [a post on 9 September](https://make.wordpress.org/plugins/2026/09/09/automated-security-review-for-plugin-releases/) - [The Backdoor Came Through the Plugin Repo, Not Around It](https://tweakswp.com/arve-plugin-backdoor-supply-chain/) - [Your WAF Protected Paying Customers on 28 July](https://tweakswp.com/waf-firewall-rule-delay-free-tier-gap/) - [@wordpress/build](https://attowp.com/wordpress-development/gutenberg-fse/wordpress-build-next-gen-plugin-tooling/) - [our WPCS MCP server post](https://attowp.com/wordpress-development/wpcs-mcp-server-how-ai-is-revolutionizing-wordpress-code-quality-for-developers/) - [will not update](https://wppioneer.com/beginners-guide/update-package-not-available-premium-plugins/) - [Wbcom Designs](https://wbcomdesigns.com) - [A five stage pipeline showing sanitisation on save, block validation,](https://attowp.com/wordpress-development/wordpress-rewrites-content-rest-api-boundaries/) - [Dark graphic headed core says the keys are strings, PHP hands you an i](https://attowp.com/wordpress-development/wordpress-core-internals-not-an-api/) - [Dark card reading agents read the accessibility tree not your CSS, com](https://attowp.com/wordpress-development/browsers-agent-plumbing-webmcp-accessibility-tree/) ## 📝 Summary - Since 5 June 2026, every plugin and theme release on WordPress.org passes through a six-hour cooldown before distribution through the update API, during which the diff is analysed by several AI models together with Jetpack Scan. - Results are cross-checked into findings with a security score; high-scoring releases are blocked automatically and every committer receives an email. Silence means the release passed — emails are sent only on block. - The Plugins Team explained this publicly on 9 September, three months after it went live, so many authors experienced an unexplained six-hour delay without knowing the cause. - The justifying incident: on 28 July a backdoor was committed to a release of a plugin with roughly 20,000 active installs. The review scored it high while still inside the cooldown, so the compromised version was never distributed, and the plugin was closed for downloads 26 minutes after Wordfence notified the team. - That incident also exposed a dependency — stopping the release required a human to act on the score — which the September change removes by making a high score block distribution automatically. - The article's most practically useful contribution is the full timeline: cooldown plus WordPress core's twicedaily update check means the realistic gap between tagging and users having a fix is six to eighteen hours. - Stakeholders: every plugin and theme author publishing through .org, their support teams, and security researchers coordinating disclosure timelines. Risk: authors who announce on tag day now advertise a release users cannot yet install. - Bottom line: a sound security trade with real release-process consequences, and the six-to-eighteen-hour figure belongs in every coordinated-disclosure agreement. ## 📖 Main Content - The mechanism is well described and the coverage gaps are called out: themes are included, which the article notes most coverage missed, and one-click dashboard updates are also gated, so no route skips the cooldown. - 'Currently six hours' is flagged as the Plugins Team's own wording, with the correct inference drawn — do not hard-code six into any tooling. - The single most important line is quoted from the announcement and correctly emphasised: 'The score measures risk, not intent.' An accidental vulnerability can score as high as deliberate malware, so a block is not an accusation. - The 28 July incident is the article's evidentiary anchor and it works in both directions — it demonstrates the system catching a real supply-chain attack before distribution, and it exposes the human-availability dependency that the September change closes. - The timeline analysis is the article's original contribution. The cooldown is widely discussed; the interaction with wp_schedule_event( time(), 'twicedaily', 'wp_update_plugins' ) is not, and it roughly doubles the realistic delay. - The WP-Cron caveat sharpens it further: on a low-traffic site the update check only runs when someone visits, so the eighteen-hour figure is a typical case rather than a worst case. - The four consequences are all actionable and correctly ordered by severity. Announcing on tag day now precedes availability; security fixes acquire a hard floor on delivery speed; a hotfix to a hotfix waits the full cooldown again with no expedited lane described; and support teams need a prepared answer because 'I don't see the update' is now expected behaviour. - The coordinated-disclosure point is the highest-stakes consequence: if a publication date is agreed with a researcher, the fix must be distributed before details go public, not merely tagged, so six hours plus margin belongs in the agreement. - The verification advice is concrete and correct — the authoritative signal is a real site on the previous version asking the update API, checked with wp plugin list after deleting the update_plugins transient to force a fresh check. - The article is transparent that its own practice is changing, which is a credibility marker rather than filler. - Sourcing is good: the Plugins Team announcement is linked directly, as are the author's own related pieces on the attack and on the WAF timing gap. - Contested by absence: no expedited lane is described for security fixes, and the article notes this without claiming none exists — the correct treatment of an unknown. ### 🗒️ Notes - Six to eighteen hours from tag to user is the number to carry away; everything else in the article supports it. - The no-email-means-passed design is worth noting as an operational detail — authors cannot infer from silence that a review has completed, only that it did not block. - Directly actionable for Courtney's releases: post-kinds, Outpost and link-extension-for-xfn all publish through .org, and the dev-* skills that describe their release flows should carry the cooldown and the announcement-timing change. - The canary-install practice — a site pinned to the previous version for each published plugin — is a small, durable piece of release infrastructure worth building once. - Cross-reference the WordPress 7.1.1 security release doc in this same batch: both concern the ecosystem's response to AI-assisted vulnerability discovery, from opposite ends (core intake versus plugin distribution). ## 📚 References - Not applicable to this source — no primary source is cited in the capture. ## 🗣️ Paraphrase - Opening: a tagged release on .org reaches nobody for six hours, through any route, while it is queued for security analysis. - The system has been live since 5 June and was explained publicly on 9 September, so authors lived with an unexplained delay for three months. - Mechanics: cooldown applies to plugins and themes and to one-click updates; several AI models plus Jetpack Scan analyse the changes; findings are cross-checked into a security score; high scores block automatically and email every committer; silence means it passed. - Emphasis: the score measures risk rather than intent, so an accidental vulnerability can score like deliberate malware and a block is not an accusation. - Justification: on 28 July a backdoor reached a release of a ~20,000-install plugin, scored high inside the cooldown, and was never distributed; the plugin was closed 26 minutes after Wordfence notified the team. - Gap closed: stopping that release still needed a person to act on the score, and the September change makes a high score block distribution by itself. - Timeline: tag at 09:00, cooldown to 15:00, then auto-updating sites pick it up on their twice-daily check, so most have it by around 03:00 — six to eighteen hours overall. - Consequence one: announcing at tag time now advertises a release users cannot install, and some will open support threads. - Consequence two: security fixes have a delivery floor that must be built into coordinated-disclosure agreements. - Consequence three: a hotfix to a hotfix waits the full cooldown again, with no expedited lane described. - Consequence four: support needs a standard reply, because a missing update in the first hours is expected. - Verification: keep a canary site on the previous version and check with WP-CLI after clearing the update transient. ## 📰 Newsletter - If you publish a plugin on WordPress.org, the number you need is six to eighteen hours — that is how long it now takes from tagging a release to your users actually having it. - Six of those hours are the security cooldown that has been running since 5 June and was only explained publicly on 9 September. Every release, plugins and themes alike, gets analysed by several AI models plus Jetpack Scan. Score high and it is blocked automatically and every committer gets an email; silence means you passed. - The rest is WordPress core checking for updates twice a day, which is easy to forget and roughly doubles the wait — longer still on a low-traffic site where WP-Cron only fires when someone visits. - It earned its keep on 28 July, when a backdoor was committed to a release of a plugin with about 20,000 installs. The review caught it inside the cooldown and it was never distributed. The plugin was closed 26 minutes after Wordfence raised it. - Three things to change: stop announcing at tag time, build six hours plus margin into any coordinated disclosure date, and give your support person a sentence explaining that a missing update in the first few hours is expected. - And keep a canary site on the previous version. Your SVN tag is not the signal — the update API is. ## ✅ Action Items #### DevRel - **Developer advocacy:** Advocate for an expedited lane for coordinated-disclosure security fixes, which the announcement does not describe. - **Education:** Teach the six-to-eighteen-hour window in any plugin release training; the twicedaily check is the part people miss. - **Developer experience:** The three-month gap between the cooldown going live and being explained is a DX failure worth naming; silent behaviour changes cost authors debugging time. #### OSPO - **Policy & Governance:** Risk-not-intent scoring is the right design and needs stating in any policy that acts on the scores. - **Security Management:** Automated pre-distribution review of releases is a supply-chain control other package ecosystems largely lack; document it as a reference implementation. #### Community - **Maintainers:** Update release runbooks: announce after cooldown, keep a canary install, prepare a support reply. - **Ecosystem:** The 28 July incident is the concrete case for why plugin supply-chain controls matter. #### WordPress - **Support:** Forum volunteers need the same standard answer plugin authors do. - **Documentation:** The release handbook should carry the cooldown, the twicedaily interaction and the WP-CLI verification recipe. - **Meta:** Surfacing cooldown status in the plugin committer view would remove the guesswork the article describes. - **CLI:** The wp plugin list verification flow is a documentation-worthy WP-CLI recipe. - **Hosting:** Hosts running managed auto-updates should understand the distribution delay before escalating missing updates. - **Tide:** Automated release analysis overlaps conceptually with Tide's scanning remit and is worth reconciling. - **Plugins:** Publish the current cooldown duration in a machine-readable place so tooling need not hard-code it, and clarify whether an expedited security lane exists. #### The WPOCC - **Programs:** Plugin supply-chain security is a candidate topic where the ecosystem now has a real case study. #### FAIR - **Technical independence:** A single centralized review gate is also a single point of control over distribution, which is exactly the dependency FAIR exists to question. ## 🧪 Hypotheses - Plugin authors who announce releases at tag time generate measurably more support tickets in the first six hours than those who announce after cooldown. - The median time from tag to distribution exceeds six hours because some reviews take longer than the nominal cooldown. - Automated pre-distribution review reduces successful plugin supply-chain compromises reaching .org users, measurable against the pre-June baseline. - False-positive blocks disproportionately affect plugins that legitimately handle file operations, serialization or dynamic code. - Sites with low traffic receive plugin security updates materially later than high-traffic sites, because WP-Cron fires on visits. ### 📊 Methodology - The mechanism description is sourced directly from the Plugins Team's 9 September announcement, which is linked, so it is reportage rather than inference. - The 28 July incident details — install count, scoring outcome, 26-minute closure — come from that same announcement and are not independently verified here. - The timeline synthesis is the author's own work, combining the announced cooldown with WordPress core's documented wp_schedule_event scheduling; the core behaviour is checkable in source. - No measurement is offered for how often reviews exceed six hours or how often legitimate releases are blocked, both of which would materially affect the practical guidance. - To test the timeline claim: tag a release on a canary-monitored plugin and record actual distribution and pickup times across several sites of differing traffic. ### ❓ Questions - Is there an expedited lane for coordinated-disclosure security fixes, and if not, how should researchers and authors set publication dates? - What is the false-positive rate, and what is the appeal path when a legitimate release is blocked? - Does the cooldown duration vary by plugin install count, code size or change surface? - Are the AI models' findings available to committers on a pass, or only on a block? - How does this interact with premium plugins distributed outside .org, which face no such gate? - What happens to a release that scores high because of an intentional but unusual pattern, such as a security plugin's own scanning code? ### 🔮 Future Research - Publishing aggregate statistics — block rate, false-positive rate, median review duration — would let authors plan rather than guess. - Whether automated pre-distribution review generalizes to other package ecosystems (npm, PyPI, Packagist) is the broader open question this implementation informs. - The security value of the cooldown depends on how quickly attackers adapt to a six-hour analysis window, which is unstudied. - Nobody has measured the real distribution curve of a WordPress plugin update across the install base, which the twicedaily-plus-WP-Cron interaction makes non-trivial. ### 💡 Implications - Practice: release runbooks need rewriting — announce after cooldown, verify via the update API rather than the SVN tag, and keep a canary install. - Practice: staging tests before tagging are worth proportionally more now, because a hotfix to a hotfix costs another full cooldown. - Policy: coordinated-disclosure agreements must budget distribution time, not just fix time, or details publish before users are protected. - Security: the 28 July case demonstrates pre-distribution review catching a live supply-chain attack, which is a stronger result than post-hoc scanning. - Education: the three-month silent rollout is a case study in how undocumented platform changes cost downstream developers time. - Funding: automated review shifts security cost from volunteer reviewer time to compute, which changes what the Plugins Team needs resourced. ### 🧠 Learning Styles Assessment - Reading level estimate: Flesch-Kincaid grade 10-11. Practitioner prose with concrete timings, WP-CLI commands and a worked timeline. #### 👀 Visual learners - Present: A step-by-step timeline with clock times is the article's clearest device. - Improve: A diagram of tag, cooldown, distribution and per-site pickup would make the two-stage delay immediately legible. #### 🔊 Aural learners - Present: No audio version. - Improve: Nothing essential; the content is reference material. #### 🗣️ Verbal learners - Present: Plain, direct, and explicit about what is quoted versus inferred. - Improve: Define SVN tag, Stable tag and cooldown for authors newer to .org publishing. #### 🧩 Kinesthetic learners - Present: Provides runnable WP-CLI commands and a concrete canary-install practice. - Improve: Nothing needed; this is the article's strongest dimension. #### 🧠 Logical learners - Present: Clean structure: mechanism, justifying incident, timeline, four consequences, verification. - Improve: Add the unknowns explicitly — false-positive rate, expedited lane — as an open-questions section. #### 🧑‍🤝‍🧑 Social learners - Present: Links to related community coverage and names the reporting sources. - Improve: Nothing needed. #### 🧘‍♀️ Solitary learners - Present: Fully self-contained and immediately actionable alone. - Improve: Nothing needed. #### 🌿 Naturalistic learners - Present: No environmental framing. - Improve: Not applicable to the subject. ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Uses headings and a numbered consequence structure; the timeline is presented as text rather than an image. - Improve: Confirm the published page marks the timeline as a list or table rather than styled paragraphs. #### Keyboard navigation - Present: Not applicable to an article. - Improve: Not evaluable from the capture. #### Contrast and readability - Present: Not evaluable from the captured text. - Improve: Ensure the inline code samples meet contrast requirements against their background. #### Text resizing and reflow - Present: Not evaluable from the capture. - Improve: The WP-CLI command lines should wrap or scroll rather than overflow at 200% zoom. #### Media and captions - Present: No media in the capture. - Improve: Not applicable. #### Forms and interactions - Present: None present. - Improve: Not applicable. #### Standards reference - Present: Relevant criteria for the published page: 1.3.1 Info and Relationships (timeline and consequence structure), 1.4.3 Contrast (code samples), 1.4.10 Reflow (command lines at 400% zoom). - Improve: Not assessable from the text capture alone. ### 🌍 DEIB Assessment #### Cultural breadth - Present: Not addressed; the audience is .org plugin authors generally. - Improve: Time-zone effects are real and unmentioned — a six-hour cooldown lands differently depending on when your working day starts. #### Inclusive language - Present: Plain and non-blaming; explicitly notes a block is not an accusation. - Improve: Expand SVN, WP-CLI and WAF on first use for less experienced authors. #### Neurodiversity support - Present: Numbered consequences, a clock-based timeline and short sections make it easy to navigate. - Improve: Nothing needed. #### Representation - Present: Institutional authorship; no individual byline to assess. - Improve: Nothing to improve. #### Psychological safety - Present: Actively reassuring — 'a block is not an accusation' and 'the team says as much' defuse the natural defensive reaction. - Improve: Nothing to improve. ### ✅ Logical Validity #### Strong reasoning - The timeline synthesis is the article's strongest reasoning: it combines an announced policy with documented core scheduling behaviour to produce a practical number nobody else had stated, and shows the derivation rather than asserting the conclusion. - Quoting 'the score measures risk, not intent' and then drawing the correct implication — an accidental vulnerability can score like malware, so a block is not an accusation — is precise and defuses a predictable misreading. - The 28 July incident is used even-handedly. It supports the system's value and simultaneously exposes the human-availability weakness the September change addresses, rather than being deployed only as vindication. - The verification advice correctly identifies the authoritative signal. The SVN tag and the plugin page are both rejected in favour of a real site querying the update API, which is the only thing that reflects distribution state. - Noting the absence of an expedited lane — 'There is no expedited lane described in the announcement' — reports an unknown as an unknown rather than asserting none exists. #### Fallacies - None identified. The source makes no argumentative move that misfires. #### Tone of voice - Direct and operational, opening with the consequence ('nobody gets it for six hours') before the explanation. - Measured about the trade-off rather than advocating either way: 'The review is the right trade. But it is a trade.' - Mildly critical of the communication gap without hostility, noting authors 'have been living with a six-hour delay they did not know existed and could not explain'. - Self-implicating where relevant — 'We are adjusting to this ourselves' — which strengthens rather than softens the advice. ### 🛡️ DARVO Analysis - **Deny:** No instance present in this source. - **Attack:** No instance present in this source. - **Reverse victim/offender:** No instance present in this source. ## 🎯 Conclusion - Six to eighteen hours from tag to users is the operative number, and it comes from the cooldown plus core's twice-daily update check plus WP-Cron's dependence on site traffic. - The security case is demonstrated rather than asserted: the 28 July backdoor on a 20,000-install plugin was scored high and never distributed, and the remaining human dependency has since been removed. - The costs are real and concentrated in release process — announcement timing, disclosure agreements, hotfix cycles and support expectations — not in the security design itself. - Next steps: move release announcements to after cooldown, build six hours plus margin into any coordinated-disclosure date, stand up a canary install per published plugin, and give support a prepared answer. ## 🔄 Refactor Appendix — WordPress.org Plugin Release Cooldown and Security Review ### 📚 Literature Atoms (H3) #### [H1] Tag-to-user delay is six to eighteen hours > [!quote] > the realistic answer to “when will my users have the fix” is somewhere between six and eighteen hours after you tag **Context & use**: - Timeline section, combining the six-hour cooldown with core's twicedaily update check - WP-Cron dependence on site visits extends this further on low-traffic sites - The number to build into any security response plan **Tags**: #xref #share <!-- atomicity: 1 idea ✓ --> #### [H2] The security score measures risk, not intent > [!quote] > The score measures risk, not intent. **Context & use**: - Quoted from the Plugins Team announcement of 9 September - An accidental vulnerability can score as high as deliberate malware, so a block is not an accusation **Tags**: #xref #aphorisms <!-- atomicity: 1 idea ✓ --> #### [H3] Cooldown stopped a real backdoor before distribution > [!quote] > because it was still inside the cooldown window, the compromised version was never distributed through the update API **Context & use**: - 28 July incident on a plugin with roughly 20,000 active installs - Plugin closed for downloads 26 minutes after Wordfence notified the Plugins Team **Tags**: #xref <!-- atomicity: 1 idea ✓ --> #### [H4] Every hotfix restarts the full cooldown > [!quote] > if you ship 2.4.0, find a fatal an hour later, and tag 2.4.1, then 2.4.1 also waits its full cooldown **Context & use**: - Third consequence for plugin authors - No expedited lane is described, so pre-tag staging tests are worth proportionally more **Tags**: #xref #addendum <!-- atomicity: 1 idea ✓ --> ### 🧠 Permanent Candidates (H4) #### [P1] Distribution delay belongs in disclosure timelines **Claim** (one sentence, Courtney's voice): A security fix protects nobody until it is distributed, so any agreed publication date must budget delivery time rather than fix time. **Evidence pointer**: [[#H1]] **Scope & conditions**: Holds wherever a gated distribution channel sits between the fix and the user; unnecessary where the maintainer controls delivery directly. **Links** (≥1 with annotation): - [[Coordinated-disclosure]] — because extends - [[WordPress-plugins]] — because applies-in release process - [[Supply-chain-security]] — because extends <!-- atomicity: 1 idea ✓ --> #### [P2] The authoritative signal is the one users read **Claim** (one sentence, Courtney's voice): Verify a release against the same source your users' software queries, because every upstream artefact can be correct while the thing they actually receive is not yet available. **Evidence pointer**: [[#H1]] **Scope & conditions**: Holds for any staged distribution pipeline; collapses where publication and availability are the same event. **Links** (≥1 with annotation): - [[Verification-before-completion]] — because extends - [[Wporg-svn-deploy-gotchas]] — because applies-in .org releases <!-- atomicity: 1 idea ✓ --> ### ✏️ Fleeting Queue - [F1] Update the dev-outpost and dev-post-kinds-for-indieweb release runbooks with the cooldown and post-cooldown announcement rule #fleeting #inbox - [F2] Stand up a canary install per published plugin, pinned to the previous release #fleeting #inbox - [F3] Is there an expedited lane for coordinated-disclosure fixes? Worth asking the Plugins Team directly #fleeting #inbox - [F4] What is the false-positive block rate, and what is the appeal path? #fleeting #inbox ### → Things 3 (max 2 actions) - [ ] Add the six-hour cooldown and post-cooldown announcement step to my plugin release runbooks #things - [ ] Create canary installs pinned to the previous version for each published plugin #things <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/WordPress.org Plugin Release Cooldown and Security Review.md|WordPress.org Plugin Release Cooldown and Security Review by AttoWP]] ## Highlights - On 28 July a backdoor was committed to a release of a plugin with around 20,000 active installations. The automated review had already been running quietly, and it caught it: the release was given a high security score, and because it was still inside the cooldown window, the compromised version was never distributed through the update API. ([View Highlight](https://read.readwise.io/read/01m2zdea49h08v1yk7dta9adw7))