Automated Security Review for Plugin Releases

Automated Security Review for Plugin Releases ![rw-book-cover](https://s.w.org/images/home/wordpress-default-ogimage.png) 🔗 **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's release workflow — what counts as "a release" for scanning purposes. The post says "the changes in each release are analyzed," which is compatible with either a code-diff-only scope or an SVN-commit-triggers-review scope that would include a readme.txt-only change. This post does not resolve that ambiguity in either direction. ## 🗒️ Notes - **Cooldown predates this announcement.** Live since June 5 (linked companion post: "Since June 5"), applying to *every* plugin and theme release, not just flagged ones — the cooldown is universal; the AI/Jetpack Scan review runs inside it for every release, and only high-scoring releases get blocked. - **Scope of "release":** covers releases distributed through the WordPress.org update API, explicitly including one-click dashboard updates. The post doesn't separately define SVN commit vs. "release" as pipeline events — it uses "release" throughout without a technical definition. - **Scanning composition:** "several AI models together with Jetpack Scan" (Jetpack Scan is an Automattic product) — count and identity of the AI models is not disclosed. Results are cross-checked against each other before being combined into one score. - **Score semantics:** higher score = higher potential risk. Explicitly *not* an intent signal — an accidental vulnerability and intentional malware can score identically. No numeric scale or threshold is published in this post. - **Blocking behavior:** automatic as soon as the review finishes (not after cooldown ends, not on a fixed schedule — event-triggered on review completion). All plugin committers (plural, not just the release author) get an email with findings when blocked. Below-threshold releases proceed through the normal cooldown with no notification either way. - **Unblock path, in order of speed per the post's own framing:** (1) read the findings, (2) fix and publish a new release — if it scores below threshold it re-enters the normal cooldown and ships, (3) contact the Plugins Team if a finding looks wrong, explicitly flagged as the slower option given review volume. - **The July 28 incident, disaggregated:** backdoor committed to a release on a plugin with ~20,000 active installs → automated review scored it high → update-API distribution blocked automatically during cooldown → separately, Wordfence notified the Plugins Team → a person closed the plugin for downloads 26 minutes later. The automated system and the manual takedown are two different actions against the same incident; the post credits the automated piece with keeping the update API clean, not with the full takedown. - **Feedback loop:** the post asks authors specifically for false-positive reports, calling that "the most useful thing plugin authors can give" toward improving the system — an explicit acknowledgment the current false-positive rate is nonzero and the system is expected to keep changing. - **What this changes operationally for an SVN-based release workflow:** a CI pipeline (e.g., a GitHub Actions SVN deploy step) that reports success on SVN commit is reporting commit success, not distribution — actual availability to update-API consumers now has a minimum ~6-hour floor plus review-completion time on top of that, and could be indefinitely delayed by a block. Any release-day checklist that treats "SVN commit succeeded" as "users can now update" is measuring the wrong event. ## 📚 References - [Automated security review for plugin releases — Make WordPress Plugins, 2026-09-09](https://make.wordpress.org/plugins/2026/09/09/automated-security-review-for-plugin-releases/) - [Since June 5 — cooldown period announcement, wordpress.org/news](https://wordpress.org/news/2026/06/pts/) - Wordfence — named in the post as the third party that notified the Plugins Team about the July 28 backdoored update; no URL given in the source, and Wordfence's own account of the incident is not linked or quoted here. ## 🗣️ Paraphrase Perez describes a two-layer system that's been partly running since June and gets a new enforcement teeth as of this post. Layer one is a universal 6-hour cooldown on every plugin and theme release before it reaches the WordPress.org update API. Layer two, running inside that window, is a combined score from several AI models plus Automattic's Jetpack Scan, cross-checked against each other to hold down false positives. What changed on 2026-09-09 is that a high score now blocks distribution the moment the review finishes, automatically, without anyone from the Plugins Team needing to be online to act on it — closing a gap exposed by a real incident on July 28, where a backdoor was caught by the automated score but the plugin listing itself still had to wait on a human to act after an outside vendor's tip. The post is careful to separate "risky" from "malicious" — the score doesn't claim to know intent, so an honest mistake gets the same block, the same email, and the same fix-and-reship path as a deliberate attack. What it doesn't do is commit to specifics: no threshold, no model list, no false-positive rate, no appeal timeline, and no explicit statement of whether a change that touches only a plugin's readme file falls inside or outside "the changes in each release" that get scanned. For anyone shipping through this pipeline, the practical upshot is that a successful SVN commit is no longer a reliable proxy for "users can update now," and every release plan should build in slack for a possible block that can only be resolved by shipping again or waiting on a busy manual queue. ## 📰 Newsletter Make WordPress Plugins just added real teeth to the release cooldown that quietly went live back in June: as of 2026-09-09, a high-risk score from "several AI models together with Jetpack Scan" now blocks a plugin or theme release from reaching the update API automatically — no Plugins Team member has to be awake to stop it. The post's receipts are a real July 28 incident: a backdoor landed in a plugin with ~20,000 active installs, and the automated score caught it inside the cooldown window before it reached anyone's auto-update queue. Worth a read for any plugin or theme author shipping through SVN — the practical takeaway is that "committed" and "distributed" are now separated by a floor of roughly 6 hours plus review time, and a false-positive block is resolved fastest by shipping a fix, not by waiting on an appeal. Full mechanics and the unresolved questions (threshold, appeal SLA, whether readme-only changes count) are in the [full post](https://make.wordpress.org/plugins/2026/09/09/automated-security-review-for-plugin-releases/) and the linked [June cooldown announcement](https://wordpress.org/news/2026/06/pts/). ## ✅ Action Items #### DevRel - Not applicable in the traditional advocacy/talks sense — but Plugin Developer Handbook documentation of this pipeline (what triggers review, what a block email looks like, how appeal works) is exactly the kind of developer-experience gap this announcement leaves open. #### OSPO - **Security Management:** directly applicable — this is a live example of vuln-intake-plus-automatic-block as institutional policy. Worth comparing this model's "score risk, not intent, block automatically, appeal manually" shape against any internal OSPO security-management policy for Courtney's own plugins. - Not applicable: Policy & Governance, License Compliance, Software Inventory, Developer Support, Community Engagement, Strategic Alignment — no content on any of these in the source. #### Community - **Contributors:** the post itself functions as a contributor-facing policy notice to every plugin/theme committer — worth tracking as a template for how the Plugins Team communicates enforcement changes (clear mechanism, one cited incident as justification, explicit ask for false-positive feedback). - Not applicable: Maintainers (beyond the above), Sponsors, Ecosystem — no content on funding, sponsorship, or cross-project incident coordination in the source. #### WordPress - **Plugins:** directly applicable — review throughput and security liaison work are the subject of the entire post; this is the Plugins Team's own security-liaison mechanism made automatic. - **Meta:** applicable — the review "in WordPress.org" and the update API's reliability under a new blocking behavior both sit on Meta infrastructure; API reliability under this new failure mode (a legitimate release silently delayed by a false positive) is a Meta-adjacent operational question the post doesn't address. - **Hosting:** applicable at one remove — hosts relying on the update API for fleet-wide plugin updates now inherit the same ~6-hour-plus-review floor and the possibility of a block; worth flagging to any host-facing release-readiness checklist. - **Tide:** worth naming the overlap explicitly — Tide is WordPress.org's existing automated plugin-scoring project (PHP compatibility and code-quality checks surfaced to users pre-install). This new system does something structurally similar (automated scoring, false-positive review loop) but for security risk, post-install, at release time. The post doesn't mention Tide or say whether the two systems share infrastructure or philosophy; that's worth someone at the Plugins/Meta level clarifying. - Not applicable: Core, Core Performance, Core AI, Core Program Team, Mobile, Playground, Community, Training, Marketing, Support, Design, Documentation, Photos, TV, Polyglots, Accessibility, CLI, Openverse, Themes — no content on any of these in the source. #### The WPOCC - Not applicable — no fellowship, funding, or governance content in the source; unrelated to The WPOCC's remit. #### FAIR - Not directly named in the source, but structurally relevant: this is another instance of a distribution gate for nominally open-source plugin code running partly on a single company's commercial scanning product (Jetpack Scan, Automattic). Worth noting as data for FAIR's independent-provenance argument without treating this post as making that argument itself — it doesn't. ## 🧪 Hypotheses - H1: Cross-checking "several AI models together with Jetpack Scan" produces a materially lower false-positive rate than any single scanner used alone would, for the same set of release diffs. - H2: The July 28 incident's ~26-minute gap between the Plugins Team being notified by Wordfence and the plugin being closed for downloads reflects a genuine human-response bottleneck that automatic blocking is specifically designed to eliminate for future incidents of the same shape. - H3: A readme.txt-only change (if such an edit registers as a new "release" in the WordPress.org SVN pipeline — a claim sourced elsewhere in today's batch, unverified here) is scanned and scored by this same system rather than being exempted as a non-code change. - H4: Shipping a fixed release resolves a block faster, on average, than waiting for a manual Plugins Team appeal review, as the post asserts without providing comparative timing data. - H5: The 6-hour cooldown window is calibrated against typical detection-to-block latency for this specific scanning pipeline, not against external disclosure-to-exploitation timelines (which can be much shorter, as in the wp2shell case referenced under Questions below). - H6: False-positive reports submitted by authors measurably reduce the false-positive rate for that same plugin's subsequent releases, rather than only feeding an undifferentiated global improvement process. ### 📊 Methodology - **H1:** Would require WordPress.org itself to run an ablation — score the same historical release diffs through Jetpack Scan alone, each AI model alone, and the combined pipeline, then compare against a labeled ground-truth set of known-malicious vs. known-clean releases. Not something Courtney can test from outside; would need to be requested from or published by the Plugins Team. - **H2:** Compare the July 28 incident's manual-response timeline (notification → closure) against the automated pipeline's own detection-to-block latency in a similar future incident, once one is public. A single before/after comparison, not a statistical test — n is inherently small for backdoor incidents. - **H3:** Directly testable by Courtney: commit a readme.txt-only change to one of her own plugins (post-kinds, Outpost, etc.) and observe whether it enters the cooldown, whether a review-triggered event appears, and whether committers receive any correspondence. Cheap, low-risk, and resolves both H3 and the unverified Burge/meta.trac claim it depends on (see Implications). - **H4:** Would need WordPress.org release/appeal timestamp data — time-to-unblock via new-release path vs. via appeal path, across a sample of blocked releases. Not available from this post; would require a data request to the Plugins Team or a FOIA-style transparency ask. - **H5:** Compare 6 hours against published exploitation-speed data from prior incidents (e.g., time-to-weaponization in the unrelated wp2shell WordPress core RCE case) to see whether the cooldown window is long enough to matter against a fast-moving attacker, or mainly effective against slow, low-effort supply-chain injection like the July 28 case. - **H6:** Would require per-plugin block-rate data over time, segmented by whether that plugin's authors filed a false-positive report after a prior block — again, data WordPress.org would need to supply; not derivable from this post. ### ❓ Questions - What is the actual appeal path and its typical turnaround once a plugin author contacts the Plugins Team about a finding that looks wrong? - Are scores or per-finding details ever published or visible to anyone besides the blocked committers, or is the scoring model a black box to authors even after a block? - Does the 6-hour cooldown apply uniformly to a *security* release — one shipped specifically to patch a vulnerability — where the delay itself carries risk, or is there a fast path? - If a readme-only edit does register as a new release (per the separate, unverified Burge/meta.trac claim), does it undergo the same AI/Jetpack Scan review as a code change, or is it out of scope because there's no executable diff to analyze? This post does not say. - Given that exploits have reportedly been weaponized within roughly 2 hours of a patch disclosure in at least one unrelated WordPress case (wp2shell), does a 6-hour distribution delay on a *patch* release widen the gap between "vulnerability disclosed" and "users protected," even while it narrows the gap for malicious injections? - Why was the plugin closed for downloads by a person 26 minutes after a Wordfence notification, rather than by the automated system that had already scored the release high risk — is takedown-from-the-directory a deliberately separate, human-gated action from update-API blocking, and if so, why? ### 🔮 Future Research - No false-positive rate is published anywhere in this post — without one, "keeps... false positives low" is an unfalsifiable claim as stated. Worth tracking whether the Plugins Team ever publishes aggregate numbers. - No comparison to Tide, WordPress.org's existing automated plugin-scoring system — unclear whether these are related infrastructure, competing systems, or entirely separate efforts that happen to both automate judgment about plugin code. - No stated review latency (how long between cooldown start and review completion, on average) — relevant to how tight a "ship at the start of a demo" risk window actually is. - No disclosure of which AI models are used or how/whether that set is versioned or audited over time — a governance-relevant gap given AI-model output is now load-bearing for whether a release reaches users. - No data yet (naturally, given how recent this is) on whether automatic blocking, rather than the pre-existing manual Plugins-Team-notices-and-acts process, actually changes outcomes for incidents shaped differently than the July 28 case — e.g., a backdoor introduced by a compromised maintainer account rather than a single bad commit. ### 💡 Implications - **Practice.** Every SVN-based release workflow now has two clocks: commit success and actual distribution, separated by a minimum ~6 hours plus review time. A CI pipeline or release-day checklist that treats "committed to SVN" as "shipped" is measuring the wrong event, and a block can extend that gap indefinitely until resolved. - **Policy/governance.** A separate, unverified finding in today's batch (Steve Burge, attributed there to meta.trac changeset 15102) claims that editing a plugin's readme.txt now itself registers as a new release in the WordPress.org SVN pipeline. This post does not confirm or address that claim, and it isn't corroborated here independently — it's flagged as unverified, not asserted as fact. *If* that claim holds, and *if* "the changes in each release are analyzed" (this post's own wording, which doesn't exclude readme-only diffs) applies to release events generically rather than to code diffs specifically, then a documentation-only edit could trigger the same 6-hour cooldown and AI/Jetpack Scan review as a code change. Neither this post nor the Burge claim states that mechanism directly — this is an open interaction between two separate, only-partially-verified facts, not a confirmed behavior. H3/Methodology above gives the cheap way to actually test it. - **Security.** The system is a genuine improvement with a cited catch (the July 28 backdoor), but it also means the WordPress.org distribution gate — the mechanism that decides whether code reaches millions of sites — now runs partly on commercial tooling from one company, Automattic (Jetpack Scan), plus an undisclosed set of AI models. That's a concrete instance of the broader "open source code, privately held infrastructure" concern raised elsewhere; this post neither raises nor defends against that framing, and this note is not asserting the dependency is a problem — only naming it as fact and a separate question from whether the review works. - **Education.** Plugin authors have no public documentation (as far as this post indicates) explaining score thresholds, appeal timelines, or scope — a Plugin Developer Handbook page walking through "what triggers a review, what a block looks like, how to respond" would close a real gap this announcement leaves open. - **Funding models.** Not applicable to this source — no funding, grant, or sponsorship content. ### 🧠 Learning Styles Assessment - **Reading level estimate:** Flesch-Kincaid Grade ≈ 9.7 (computed directly from the captured text: 542 words, 37 sentences, ~900 syllables). Consistent with a plain-language institutional announcement — short sentences, technical WordPress vocabulary (cooldown, distribution, update API, committer) without much hedging or subordinate-clause complexity. #### 👀 Visual learners - **Present:** none — the post is text-only; no diagram of the cooldown timeline, the scoring pipeline, or the unblock decision tree. - **Improve:** a simple flow diagram (commit → cooldown starts → AI + Jetpack Scan → score → below/above threshold → distribute/block → fix-and-reship or appeal) would make the mechanism scannable in seconds instead of requiring a full read. #### 🔊 Aural learners - **Present:** none — no audio or video companion referenced. - **Improve:** a 2-minute audio summary aimed at plugin authors (not just the written post) could reach committers who skim make.wordpress.org via email digest rather than reading the full post. #### 🗣️ Verbal learners - **Present:** the score-vs-intent distinction is defined clearly and directly in-text, with a worked contrast (accidental vulnerability vs. intentional malware scoring identically). - **Improve:** "release" is used throughout without a technical definition (SVN commit event? tagged version? both?) — a one-line glossary entry would remove the exact ambiguity this note flags repeatedly above. #### 🧩 Kinesthetic learners - **Present:** the three-step unblock procedure (review findings → fix and republish → contact Plugins Team if needed) is concrete and numbered. - **Improve:** no sample block email or sample findings report is shown — a redacted real example would let an author rehearse the response before ever receiving one. #### 🧠 Logical learners - **Present:** clear conditional structure throughout (if score is high → block; if new release scores below threshold → normal process; if finding looks wrong → contact team). - **Improve:** an explicit decision table (score range × release type × resulting action) would make the branching logic auditable instead of narrated in prose. #### 🧑‍🤝‍🧑 Social learners - **Present:** the closing ask for false-positive feedback functions as a light collaborative loop between authors and the Plugins Team. - **Improve:** no forum, comment thread, or discussion venue is linked for authors to compare block experiences with each other — worth checking whether the Plugins Team Slack channel or a wp.org support forum thread exists for this. #### 🧘‍♀️ Solitary learners - **Present:** the unblock path is designed for a single author to resolve alone (read findings, fix, republish) without needing to coordinate with anyone. - **Improve:** none needed — this is already well-suited to independent resolution. #### 🌿 Naturalistic learners - **Present:** none — no ecological or systems-in-nature framing, and the content doesn't lend itself to one. - **Improve:** not a natural fit for this content; no changes recommended. ### 📊 Accessibility Assessment *Assessed from the captured HTML only — a plain text/headings/list post with no images, embeds, or interactive elements.* #### Screen reader semantics - **Present:** proper semantic structure — `<h2>` section headings ("Why we're doing this," "How it works," "When a release is blocked," "Feedback"), an ordered list (`<ol>`) for the three-step unblock procedure, and `<strong>` used for emphasis rather than styling-only markup. - **Improve:** none needed at the structural level; the source markup already satisfies WCAG 2.2 SC 1.3.1 (Info and Relationships) and SC 2.4.6 (Headings and Labels). #### Keyboard navigation - **Not observed** — no interactive elements (forms, widgets, embedded tools) in the captured content; not applicable (would map to SC 2.1.1, 2.4.3 if the published page adds any interactive component not present in this capture). #### Contrast and readability - **Not observed** — text contrast on the live page wasn't visually reviewed here; flag for direct review before treating as compliant (WCAG 2.2 SC 1.4.3, SC 1.4.11). #### Text resizing and reflow - **Not observed** — no reflow-relevant UI in the captured content (SC 1.4.4, SC 1.4.10 would need direct browser review of the live page, not this text capture). #### Media and captions - **Not applicable** — no audio, video, or image content in the post beyond a generic default social-share image; no captioning requirement applies. #### Forms and interactions - **Not applicable** — no forms or interactive input anywhere in the captured content. #### Standards reference - Gaps above (all "not observed," none "failing") map to WCAG 2.2 AA: 1.4.3, 1.4.4, 1.4.10, 1.4.11, 2.1.1, 2.4.3 — all require direct review of the live published page, which this text-only capture doesn't provide. The structural criteria that *can* be assessed from the capture (1.3.1, 2.4.6) are met. ### 🌍 DEIB Assessment #### Cultural breadth - **Present:** none directly — the post is a procedural announcement with no regional, linguistic, or cultural framing one way or the other; the WordPress.org plugin ecosystem itself is globally distributed, but the post doesn't address translation, locale-specific rollout, or non-English-speaking author support. - **Improve:** a note on whether block-finding emails are localized for non-English-speaking committers would be a concrete, checkable addition. #### Inclusive language - **Present:** plain, direct, non-gendered language throughout ("authors," "committers," "the team"); no idiomatic phrasing likely to translate poorly. - **Improve:** none needed; the register is already plain and unambiguous. #### Neurodiversity support - **Present:** short paragraphs, clear numbered steps for the unblock procedure, and a consistent question-and-answer-like structure (why we're doing this → how it works → when blocked → feedback) that aids predictability. - **Improve:** none needed at this length; the structure is already low-friction. #### Representation - **Present:** no named individuals beyond the byline (David Perez) and references to the Plugins Team and Wordfence as institutional entities, not individuals — no representation concerns arise because no people beyond the author are characterized. - **Improve:** not applicable — there's nothing in the content to improve on this axis. #### Psychological safety - **Present:** the post explicitly reassures authors that a high score isn't an accusation of malice — a direct, well-placed de-escalation for anyone who receives a block email and might otherwise read it as a wrongdoing finding. - **Improve:** none needed; this is already handled better than most security-process announcements manage. ### ✅ Logical Validity #### Strong reasoning - **Causal/mechanistic reasoning on why automatic blocking closes a real gap (main content, "the missing piece" quote):** the argument that a high-risk result should stop distribution without depending on Plugins Team availability is directly grounded in the July 28 incident, where the automated *detection* happened but the full *takedown* still needed a person and an external notifier. That's a specific, load-bearing causal chain (detection alone isn't enough → therefore automatic blocking closes the remaining gap), not a bare assertion. - **Careful scope-limiting on score semantics:** the explicit statement that a high score doesn't imply malicious intent is a deliberately narrow, well-calibrated claim — it avoids overclaiming what the scanning system can actually determine (risk) versus what it can't (motive), and it's consistent with how the rest of the post treats blocked authors (assume error, not wrongdoing, by default). #### Fallacies - **Single-incident generalization presented as system validation.** Location: the July 28 backdoor is the only concrete evidence offered for the entire automated-blocking system's value, yet the post frames the launch as a general policy improvement rather than "this worked once, for this kind of incident." Why it's weak: n=1 doesn't establish a false-positive rate, doesn't establish performance against a faster-moving or better-hidden attack, and doesn't establish anything about how often legitimate releases get caught in the net. Fix: pairing the incident story with aggregate numbers (false-positive rate, block rate, average time-to-resolution) would turn a persuasive anecdote into actual evidence. - **Understated evidence for a comparative claim.** Location: "publishing a fixed release is almost always faster than waiting for a manual review of an appeal." Why it's weak: this is a comparative timing claim with no data behind it in the post — it may well be true given stated review-volume pressure, but it's asserted, not measured or cited. - **Blurred boundary between the automated system and the incident's actual resolution.** Location: the July 28 narrative reads as one continuous success story, but as the Main Content section above unpacks, the automated review stopped update-API distribution while a human closed the plugin's downloads 26 minutes after an *external* vendor's notification. The post doesn't claim the automated system did the full takedown, but it also doesn't clearly separate the two actions for the reader — a reader skimming could easily credit the AI/Jetpack Scan pipeline with catching *and* stopping the incident end-to-end, when the sourced text only supports the first half. #### Tone of voice - Institutional, reassuring, procedural — first-person plural ("we're launching," "we're doing this"), short declarative sentences, explicit de-escalating language around intent, and a closing tone that treats the audience as collaborators ("Feedback about false positives is the most useful thing plugin authors can give us") rather than as a population being policed. ### 🛡️ DARVO Analysis - **Deny:** Not applicable — this is a Plugins Team security announcement, not a response to an accusation against the Team or WordPress.org. There is no denial pattern because no one has accused the post's author or WordPress.org of wrongdoing that the post is responding to. - **Attack:** Not applicable — no critic, accuser, or rival party is named or attacked anywhere in the source. If anything, the only "adversary" implied is the unnamed party who committed the July 28 backdoor, and even they are not directly attacked rhetorically — described factually, without editorializing language. - **Reverse victim/offender:** Not applicable — no victim/offender reversal appears. The post's institutional actor (WordPress.org / the Plugins Team) frames itself as responding to a real incident and closing a gap in its own prior process ("that incident also made clear the missing piece"), which is closer to an institution accepting a process gap existed than to reframing itself as a victim. Worth noting as the actual rhetorical move present instead of DARVO: mild institutional self-correction ("until now there was no consistent review step... that's the missing piece we're launching now") rather than defensiveness. ## 🎯 Conclusion The post commits to something narrow and real: every plugin and theme release now clears a 6-hour cooldown during which several AI models plus Jetpack Scan produce a cross-checked risk score, and a high score blocks distribution automatically, with no Plugins Team member needing to act in real time. It does not commit to a published threshold, a false-positive rate, an appeal SLA, or a precise definition of what counts as "the changes in each release" for scanning purposes — that last gap is exactly where the unverified, separately-sourced claim about readme-only edits counting as releases would matter most, and this post gives no basis to resolve it either way. Practical next step for Courtney: treat SVN commit success and actual user-facing distribution as two different events in any release-day plan, and — cheaply and directly — commit a readme-only change to one of her own plugins to observe firsthand whether it enters this same cooldown-and-scan pipeline, which would settle H3 and the Burge/meta.trac interaction without waiting on WordPress.org to document it. ## 🔄 Refactor Appendix — Automated security review for plugin releases > Density: 4 Literature atoms, 1 Permanent candidate. > Konik claim-header rules: present tense, declarative, ≤10 words, searchable, unique. > Atomicity: one declarative sentence per atom. ### 📚 Literature Atoms #### [H1] Score measures risk, not intent > [!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. **Context & use**: - Stated directly in the "How it works" section, immediately after describing how blocking triggers. - Load-bearing for how a blocked author should interpret and respond to a finding — treat it as a bug to fix, not necessarily an accusation. **Tags**: #xref #aphorisms  #### [H2] Automatic blocking closes the human-availability gap > [!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. **Context & use**: - Directly follows the July 28 incident narrative; states the specific design rationale for the feature this post announces. - The prior system (manual Plugins Team review/action) is implicitly named as the gap being closed. **Tags**: #xref  #### [H3] Automated review caught a backdoor inside the cooldown window > [!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. **Context & use**: - The post's sole concrete evidence for the system's value; used as justification for the automatic-blocking launch. - Pairs with [H4] below, which shows the full incident resolution needed a separate manual step. **Tags**: #xref  #### [H4] Takedown followed a human response to Wordfence, not the automated block > [!quote] > The plugin was closed for downloads 26 minutes after the Plugins Team was notified by Wordfence about the update. **Context & use**: - Immediately follows [H3] in the source; establishes that the plugin's directory listing was closed by a person, after an external vendor's notification — a separate action from the automated update-API block. - Central to the Logical Validity finding above about blurred credit between the automated system and the incident's actual resolution. **Tags**: #xref  ### 🧠 Permanent Candidates #### [P1] SVN commit success is not distribution success **Claim** (Courtney's voice): When I ship a plugin release through SVN, the commit succeeding tells me nothing about whether users can actually update yet — that now depends on a ~6-hour cooldown plus an AI/Jetpack Scan review I don't control or see in advance. **Evidence pointer**: [[#H2]] **Scope & conditions**: Applies to any plugin or theme release distributed through the WordPress.org update API, including one-click dashboard updates. Doesn't apply to code hosted only on GitHub outside the update API, or (per this post, unresolved) possibly doesn't apply the same way to non-code releases — unverified, see H3/Methodology above for the direct test. **Links** (≥1 with annotation): - [[wp.org SVN deploy gotchas]] — because extends: this adds a distribution-timing gotcha on top of the existing SVN password/deploy mechanics already logged there. - [[Deploy-repo push authorization]] — because applies-in: any release-day checklist assuming "pushed" equals "shipped" needs this cooldown-plus-review floor built in explicitly. **Optional**: `proof_state: working` — testable directly by observing a real release's block/no-block behavior and timing.  ### ✏️ Fleeting Queue - [F1] Commit a readme.txt-only change to one of my own plugins and watch whether it enters the same cooldown/review pipeline — settles H3 and the Burge/meta.trac readme-as-release claim empirically. — #xref - [F2] Check whether Tide (WordPress.org's existing automated plugin-scoring project) and this new security-review pipeline share any infrastructure, or are functionally unrelated systems that happen to both auto-score plugin code. — #xref ### → Things 3 (max 2 actions) - [ ] Update the release-day checklist for post-kinds, Outpost, link-extension-for-xfn, post-formats-for-block-themes, and Social Webmention Importer to treat SVN commit and actual distribution as separate events with a ~6-hour-plus floor — context #release-workflow #things - [ ] Verify committer lists are current on all five actively-shipped plugins so a block email reaches someone who can act on it — context #release-workflow #things  📄 **Full text:** [[Full Document Contents/Articles/Automated Security Review for Plugin Releases.md|Automated Security Review for Plugin Releases by David Perez]] ## Highlights - 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. ([View Highlight](https://read.readwise.io/read/01m25knvwhx7t1br1pcs9v7d4k)) - Note: The incident that justifies the whole mechanism, with real numbers: ~20,000 active installs, caught inside the cooldown, never distributed, closed 26 minutes after Wordfence notified the team. The stated lesson is that blocking shouldn't depend on a human being awake. - Tags: plugin-directory, supply-chain-security, atom/literature/h1 - 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. ([View Highlight](https://read.readwise.io/read/01m25knzzsbk5m3fc0p2w7r9dk)) - Note: The gate that decides whether a wp.org release reaches users runs on several AI models plus Jetpack Scan — an Automattic product. Structure, not accusation: the review looks like a genuine improvement, and the dependency is a separate question. Note the honest hedge: false positives low, "but not zero." - Tags: release-engineering, atom/literature/h2, ai-security-review ## New Highlights added 2026-09-10 at 10:41 AM - During the cooldown, the changes in each release are analyzed in WordPress.org by several AI models together with Jetp ([View Highlight](https://read.readwise.io/read/01m25w0qrxx8epc49bbgehwwp6)) - Note: The mechanism. Note it never scopes "changes in each release" to code-only — which is why the readme-as-release finding matters. - Tags: plugin-security, xref - Cross-checking multiple tools keeps accuracy high and false positives low, but not zero. ([View Highlight](https://read.readwise.io/read/01m25w0tnnzf1zdja0tr7kwwbq)) - Note: No numeric threshold, false-positive rate, or appeal SLA is given anywhere in the post. - Tags: xref, plugin-security