WordPress.org has launched an automated security review for plugin releases, adding a new check designed to identify potential security risks before updates are distributed through the WordPress.org update API.
Plugin releases identified as high risk will be blocked automatically, with plugin authors notified of the findings.
How the new security review works
David Perez said the new review addresses a gap in how plugin updates were handled after a plugin entered the WordPress.org directory. While new plugins are reviewed before being listed, their later releases can introduce new security issues. As Perez noted, “A plugin can be secure today and introduce a vulnerability, or malicious code, in a future release. Until now, there had been no consistent review step between an update being committed and reaching WordPress sites.”
The review takes place while releases are held in the cooldown period, introduced during the Protect The Shire Initiative, before being made available through the WordPress.org update API.
WordPress.org now uses several AI models and Jetpack Scan to analyze the changes in each plugin and theme release as stated, “ 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. “
Releases that receive a high-risk score will now be blocked automatically once the review is complete, while those below the blocking threshold will continue through the normal process. Perez also stressed that the score does not determine whether harmful code was introduced deliberately, “The score measures risk, not intent.” An unintentionally introduced vulnerability can therefore be assessed as posing just as much risk as intentional malware.
The existing cooldown period played an important role when Wordfence detected a backdoor in Advanced Responsive Video Embedder, a plugin with around 20,000 active installations, less than two hours after the malicious code was introduced.
The compromised release was still within the Protect The Shire’s cooldown window when it was identified. As a result, it had not yet been distributed through the WordPress.org update API, meaning sites had not automatically received the malicious version. Wordfence then reported the issue to the WordPress.org Plugins Team, which closed the plugin for downloads 26 minutes after being notified.
The incident also highlighted what Perez described as the missing piece in the process,“A high-risk result should stop distribution automatically, without depending on someone from the Plugins Team being available.”
When a release is blocked, all plugin committers will receive an email containing the findings. They can address the reported issues and publish a new release. If that version scores below the blocking threshold, it will continue through the normal cooldown process.
Authors who believe a finding is incorrect can contact the Plugins Team. However, Perez noted that “publishing a fixed release is almost always faster than waiting for a manual review of an appeal.”
For now, emails will only be sent when a release is blocked, so authors who do not receive one do not need to take any action. Perez said the process will continue to evolve as more data is collected and the checks are refined, with feedback on false positives helping improve the system.