www.it-connect.fr
WordPress Now Blocks High-Risk Plugin Updates Automatically with AI
On the WordPress.org side, a decision has been made to strengthen the platform’s security: every new plugin release is now automatically analyzed, and versions deemed high-risk are blocked without human intervention. Here’s what you need to know.
As a reminder, the official WordPress library (available at wordpress.org) hosts more than 78,000 plugins and themes. That is a huge number and it shows just how active the WordPress ecosystem is. Until now, a plugin’s security was manually reviewed only when it was first submitted to appear in the official repository. That meant that once the plugin was published, every update was approved automatically and pushed directly to WordPress sites without any new verification.
"An extension can be safe today and introduce a vulnerability, or malicious code, in a future version," reminds David Perez, co-lead of the Plugins team, in the announcement published on September 9, 2026. I can only agree with that statement. This is all the more true in the wake of the rise in software supply chain attacks.
There is also a concrete example involving WordPress directly. In July 2025, I wrote an article about the backdoor distributed for two days through the Gravity Forms plugin, after the publisher’s account was compromised. We can also mention the Essential Plugins case, where around thirty legitimate extensions were acquired by a malicious actor who injected a backdoor into them.
And on July 28, 2026, history nearly repeated itself. A backdoor was committed into a new version of a plugin with around 20,000 active installations (we do not know its name). The automated analysis detected it, and that malicious version was never distributed after being blocked by a member of the WordPress Plugins team. A success, then.
But this failed attempt to distribute an infected plugin exposed a weak link, or rather a fragile one: the analysis had done its job, but the blocking still depended on the availability of a member of the Plugins team. In other words, what happens if the malicious commit arrives on a Sunday at 3 a.m.? Nothing — the malicious update would likely be distributed. Well, that was before.
What Changes in September 2026
As a reminder, on June 5, 2026, WordPress.org launched the Protect The Shire initiative, with the goal of securing its official themes and plugins library. Since then, every new release has gone through a "cooldown period" before being distributed via the update API, including one-click updates from the dashboard. Initially set to 24 hours, this delay was reduced to 6 hours in mid-July.
Until now, this cooldown period was just a delay: a window during which tools and humans could review the code, with no guarantee that a suspicious release would be blocked before the countdown ended. Now, WordPress has decided to take things a step further as of September 9:
- Blocking is automatic. As soon as the analysis is complete, a release with a high-risk score is blocked as a precaution, without human validation (even if it’s a Sunday at 3 a.m.).
- The process is formalized and public. Risk score, developer notifications, and the steps required to unblock a release.
During this 6-hour observation period, changes in each release are reviewed by several AI models, alongside Jetpack Scan. The results are cross-checked, combined, and assigned an overall security score. The higher the score, the greater the potential risk. According to WordPress, this cross-checking keeps false positives low, but not zero.
One important point: a high score does not mean malicious intent. It may simply be a development mistake, since a vulnerability introduced unintentionally can receive the same score as malware. "The score measures risk, not intent," David Perez explains. But in the end, a blocked release will not be distributed until the issues have been fixed.
This is pretty good news for the WordPress ecosystem. This automated analysis should help improve the overall security of plugins, even though it also depends on the scope of the analysis when looking for vulnerabilities.
