WordPress Automates Security Reviews for Plugin Releases
WordPress has begun automatically reviewing every plugin release before it is distributed through the WordPress.org update API. The control combines AI models with Jetpack Scan during a cooldown period and can automatically stop releases that receive a high-risk score.
The new process follows a July 28, 2026 incident in which the review detected a backdoor in a release for a plugin with about 20,000 active installations. The compromised version was still inside the cooldown window, so it was never distributed through the update API. Wordfence alerted the Plugins Team, and the plugin was closed for downloads 26 minutes later.
A review stage between commit and distribution
New plugins have long been reviewed before entering the directory, but subsequent updates can be committed continuously. David Perez, co-lead of the WordPress Official Plugin Repository Team, said a plugin that is safe in one release can acquire a vulnerability or malicious code in a later version.
Since June 5, 2026, plugins and themes have passed through a cooldown period under the Protect The Shire initiative. That delay was initially 24 hours and is now six hours. The automated review adds a consistent examination step before an update reaches downstream users.
During the cooldown, WordPress.org analyses each release with AI models and Jetpack Scan, cross-verifies the results, and combines them into a security score. A release above the high-risk threshold is blocked once the review is complete without Plugins Team intervention. Releases below the threshold continue through the normal process.
What can raise the risk score
A high score does not by itself establish malicious intent. It can also identify security weaknesses introduced unintentionally. Perez said the review looks for vulnerability classes considered in a security audit, an issue illustrated by critical WordPress flaws and takeover risks and the risks posed by critical WordPress flaws.
Examples include REST, AJAX and admin-post endpoints without a capability check; a nonce alone is not authorization. The system also considers database queries built without $wpdb->prepare(), file operations derived from request data, unserialize() used on request data or remote responses, and settings written by subscriber-accessible or unauthenticated endpoints.
Runtime-fetched or evaluated code, plus obfuscated or packed code, may also increase the score. WordPress advises developers to follow WordPress Coding Standards and PHP_CodeSniffer rules. Publishers of WooCommerce extensions are also directed to the Quality Insights Toolkit testing platform.
Implications for plugin publishers and site operators
When a release is blocked, its publisher must review the findings, correct the issues, and publish a new release. If the replacement scores below the threshold, it proceeds through the ordinary cooldown. Authors may contact the Plugins Team over an incorrect finding, but Perez said publishing a fixed release is usually faster than awaiting manual appeal review.
For businesses operating WordPress sites, the change makes repository-delivered updates subject to an additional supply-chain safeguard, not a substitute for internal controls. Teams should still test important updates, maintain inventories of installed plugins, and require developers to validate authorization, database handling and file-processing code before release.