WordPress.org is now running every plugin release through an automated security review before it goes out through the update API, and blocking the ones that score too risky before a single site auto-updates into it. The WordPress Plugins Team announced the system on September 9, 2026, built on top of the “Protect The Shire” cooldown period that has delayed plugin and theme releases since June 5. Any plugin developer pushing an update to WordPress.org is affected, and so is every site running on auto-updates.
How the Review Actually Works
Every release now sits in a cooldown window, currently six hours, down from the 24 hours it started at in June. During that window, WordPress.org runs the changed code through several AI models alongside Jetpack Scan, cross-checks the results, and rolls them into a single security score. According to the Plugins Team’s announcement, the system flags things like unprotected REST and AJAX endpoints, database queries that skip $wpdb->prepare(), unsafe file operations built from request data, and unsafe deserialization. A release that scores high risk gets blocked automatically as soon as the review finishes, before it ever reaches the update API or a site’s one-click update button. The developer gets an email. Nobody else finds out unless they go looking.
David Perez, the Plugins Team’s co-lead, put the gap this closes plainly: “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.”
The Backdoor That Made the Case for It
WordPress.org’s own example is a plugin with roughly 20,000 active installations that had a backdoor committed to a release on July 28, 2026. The automated review scored it high risk during the cooldown window, so the compromised version never made it into the update API or onto anyone’s site. Wordfence flagged the same release to the Plugins Team separately, and the plugin was pulled from the directory 26 minutes later. That is close to the outcome ConicPlex covered with the BdThemes supply chain attack earlier this year, except this time the bad release got caught before it shipped instead of after.
What This Means if You Run or Build on WordPress
For site owners, this is a real reduction in one specific risk: a trusted plugin turning malicious in an update you auto-install without reading the changelog. It is not a reason to stop watching. The review catches patterns, not every possible exploit, and it says nothing about vulnerabilities already sitting in a plugin’s current version, like the RCE flaws and option-deletion bugs this space covers most weeks.
Plugin developers face a different consequence: a blocked release means at least a six-hour delay and a fix before it reaches users, on top of the existing review queue for new submissions. That is worth planning around, especially anything shipping close to a deadline. If your release process doesn’t already run its own static analysis or dependency checks before a tag goes out, the WordPress.org review is now your last line of defense, not your first one, which is a good argument for building that checking in earlier. It is exactly the kind of gap a Plugin Development engagement is built to close for teams shipping WordPress.org releases without a dedicated security review step of their own.
Sources
- Automated security review for plugin releases (Make WordPress Plugins)
- Protect The Shire (WordPress News)
- WordPress Adds Automated Plugin Reviews to Block High-Risk Updates Before Distribution (The Hacker News)
