An automated review detected a backdoor committed to a release of a plugin with about 20,000 active installations on July 28, 2026 — and that compromised build never reached end users because the new review process caught it during a cooldown window.
What WordPress is adding: automated reviews before the update API
WordPress has launched an automated security review that runs against every plugin release before it is distributed through the WordPress.org update API. The company framed the change as closing a straightforward gap: "New plugins are reviewed before they enter the directory, but updates ship continuously after that," David Perez, WordPress Official Plugin Repository Team Co-Lead, said. A missing, consistent review step between commit and release, WordPress said, left an opening for malicious updates and inadvertent vulnerabilities to reach downstream sites.
Protect The Shire and the cooldown window
Since June 5, 2026, WordPress has placed every plugin and theme into a cooldown period before distributing them via auto-updates, as part of an initiative called Protect The Shire. The cooldown window was originally 24 hours and is currently six hours. The cooldown is designed to introduce friction so that potentially malicious or vulnerable updates do not reach users immediately — and in the July 28 incident the cooldown window allowed the automated review to identify the backdoor before distribution.
Audit-ready is a season. It shouldn't be.
Evidence in spreadsheets, controls drifting between audits, frameworks multiplying on flat headcount. Nubivance runs continuous compliance on Rapid7 Cyber GRC - SOC 2, HIPAA, ISO 27001, PCI, CMMC.
End the scrambleHow the automated review and risk scoring work
During the cooldown period, WordPress analyzes the changes in each release using artificial intelligence models alongside Jetpack Scan. Results are cross-verified and combined into a single security score: higher scores indicate potentially higher risk. Releases that exceed the high-risk threshold are automatically blocked once the review completes; releases that score below that threshold proceed through the normal update process. When a release is blocked, plugin committers receive an email containing the findings — emails are sent only in scenarios where a plugin is blocked.
Specific patterns that drive a high-risk score
- REST, AJAX or admin-post endpoints without a capability check (a nonce alone is not authorization)
- Queries built without $wpdb->prepare()
- File paths, uploads, deletions or includes constructed from request data
- unserialize() on request data or on a remote response
- Options, user meta or settings written from endpoints reachable by subscribers or unauthenticated users
- Code fetched or evaluated at runtime, and obfuscated or packed code
WordPress emphasized that the review looks for "the same vulnerability classes any security audit looks for." Perez urged developers to follow WordPress Coding Standards and PHP_CodeSniffer (PHPCS) rules to validate code quality; developers publishing WooCommerce extensions were recommended to use the Quality Insights Toolkit (QIT) testing platform.
Remediation, appeals, and the Plugins Team role
If a release is blocked, the only route to restore distribution is for the developer to review the findings, fix the issues, and publish a new release. Should that new release score below the high-risk threshold, it will continue through the normal cooldown process. Perez noted that authors can contact the Plugins Team if a finding looks incorrect, but cautioned 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." The automated block mechanism is intended to halt distribution without Plugins Team intervention whenever a release scores as high risk.
What this means for developers, WordPress security teams, and end users
- Developers: Expect an automated scan during every release cooldown and an email only if your release is blocked; follow PHPCS and the Coding Standards to reduce false positives and legitimate risk flags.
- WordPress security teams: The new automation lets AI models and Jetpack Scan block high-risk releases without immediate human intervention, narrowing the window for malicious updates to reach users while reserving manual effort for appeals and complex cases.
- End users and site operators: The cooldown and automated scoring introduced under Protect The Shire add delay but also a safety layer; in at least one July 28 incident a compromised build was never distributed because it was caught during that window, and the plugin was closed for downloads 26 minutes after the Plugins Team was alerted by Wordfence.
The change folds detection and enforcement into the release pipeline itself: rather than relying solely on post-release human review or downstream reporting, the update process now pauses long enough for automated analysis and an automatic stop when risk is high. The approach accepts some friction to reduce the chance that a vulnerable or malicious update can propagate through the WordPress.org update API.
