WordPress Adds Automated Plugin Reviews to Block High-Risk Updates Before Distribution

On 9 September 2026, the WordPress.org Plugins Team announced that every plugin release is now put through an automated security review before it is distributed through the WordPress.org update API. Releases that score as high risk are blocked automatically, without anyone from the team having to be awake to press a button. For anyone who runs WordPress sites, this is the first time there has been a consistent, enforced check between a developer committing a release and that release landing on your site.

It is a real improvement, and it is narrower than the headline suggests. The automated plugin security review gates a release on its way out of wordpress.org. It has no view of the code already sitting in your wp-content/plugins directory, no reach over plugins that update from anywhere else, and no way of telling a security fix apart from a button-colour change. Knowing exactly where that line falls is what decides whether anything about your update process should change this week.

TL;DR

• Since 9 September 2026, every plugin release published to WordPress.org is analysed during its cooldown window by several AI models together with Jetpack Scan, and releases scoring high risk are blocked from the update API automatically.
• The cooldown itself has been in place since 5 June 2026 as part of the Protect the Shire initiative. It started at up to 24 hours and is currently 6 hours, a number that has already changed once with no public announcement.
• The same clock gates background auto-updates, the "Update now" button in wp-admin, wp plugin update, and any management tool built on the update API. Your dashboard can show an older version than the plugin's own page does.
• The check covers directory-hosted plugin releases only. Premium plugins updating through their own channels, hand-installed ZIPs, custom functionality plugins and already-installed code are all outside it.
• It does not fast-track security releases. A patch for a critical vulnerability waits in the same queue as a routine release, which is the trade-off worth watching.

What WordPress actually launched

The announcement came from David Perez, co-lead of the WordPress.org Plugins Team, on the Make WordPress Plugins blog. The reasoning behind it is straightforward: new plugins are reviewed before they are allowed into the directory, but updates ship continuously after that, and nothing consistent sat between a commit and millions of sites. A plugin can pass review, run cleanly for years, and introduce a vulnerability or malicious code in any release after that.

The mechanics build on something that was already running. Since 5 June 2026, under the initiative WordPress.org named Protect the Shire, every plugin and theme release has waited in a cooldown window before being distributed through the update API. During that window, the changes in the release are analysed by several AI models alongside Jetpack Scan. The results are cross-checked against each other and combined into a set of findings with a single security score, where higher means more potential risk. Using more than one tool and comparing the outputs is what keeps false positives down, though the team is clear that it does not get them to zero.

What changed on 9 September is the consequence of a high score. Previously the analysis produced a result that someone had to act on. Now a release that scores above the blocking threshold is stopped as soon as the review finishes, and everyone with commit access to that plugin gets an email describing the findings. Releases below the threshold carry on through the normal cooldown and are distributed as usual. Emails only go out on a block, so a developer who hears nothing has nothing to do.

One line in the announcement deserves more attention than it usually gets in the coverage: the score measures risk, not intent. An accidental capability check left off a REST route can score as high as a deliberately planted backdoor, because the system is measuring what an attacker could do with the code, not what the developer meant to write. If you are a plugin author, a block is not an accusation.

The numbers behind the threshold are not public

WordPress.org has not published where the blocking threshold sits, what the score range is, or which of the AI models carry the most weight in the combined result. That is a defensible choice, since publishing the scoring rules of a system designed to catch deliberately hidden code hands the same information to the people writing it. It also means nobody outside the Plugins Team can predict in advance whether a given release will clear the gate, and there is no public data yet on how often a legitimate release gets held.

Why automate the block, and not just the alert

The specific event that pushed this over the line happened on 28 July 2026. A backdoor was committed to a release of a plugin with around 20,000 active installations. The automated review caught it and gave it a high score, and because the release was still inside its cooldown window, the compromised version was never distributed through the update API. The plugin was closed for downloads 26 minutes after Wordfence notified the Plugins Team.

That plugin was Advanced Responsive Video Embedder, and the release was 10.8.7. The resulting record, CVE-2026-18072, is rated CVSS 9.8. The mechanism was about as direct as authentication bypasses get: a function hooked to init at priority 1, so that it ran on every request before WordPress performed any authentication, read a token from a query parameter and compared it against a SHA-256 hash hardcoded into the plugin source. Anyone who read the source could send that token and be logged in as an administrator of their choosing. Wordfence reported that its automated system flagged the code less than two hours after it was introduced.

Read the sequence carefully, because the useful lesson is in the ordering. Detection already worked. The automated review scored the release correctly on its own. What did not exist yet was a path from "the scanner says this is bad" to "this release stops moving" that did not require a human being to receive a notification and act on it. In the ARVE case that human action came 26 minutes after an outside security vendor sent an email, which is fast, and which is also entirely dependent on the vendor watching, the email arriving, and someone being at a keyboard in the right timezone. The change announced in September removes those three dependencies for the blocking decision.

This is also worth saying plainly: one incident is a data point, not a track record. The system stopped one documented supply-chain attempt inside a cooldown that was already holding every release anyway. Whether it holds up against a backdoor written specifically to score low is an open question, and the honest answer is that nobody knows yet.

Where the gate sits in the release pipeline

This is the part that causes the most confusion, and it matters more day to day than the security mechanism itself.

A plugin release goes through three separate moments: the developer tags the version, the release ZIP becomes downloadable from the directory, and the update API starts telling sites that a new version exists. Tagging to downloadable is close to instant. The cooldown, and therefore the block, sits at the third step. The version exists, its page can show it, and your site still will not be offered it.

The consequence is that one clock now gates several things people think of as different:

The original Protect the Shire announcement described the delay in terms of auto-updates, and a lot of the early reporting repeated that framing. Developers found out within hours that the manual button was gated on the same clock, and the security company Patchstack later measured the behaviour directly across more than a hundred releases rather than taking the description at face value. Its daily median for the hold sat at roughly 24 hours through mid-July and then dropped to a shade under seven hours in a single day, matching the reduction of the cooldown from 24 hours to 6. That reduction was mentioned in a Slack channel rather than published as a post, which is the clearest signal available that the cooldown duration is an operational setting rather than a policy number. Treat any specific figure, including the 6 hours quoted here, as something to re-check against the Make WordPress Plugins blog before you plan around it.

Patchstack also documented the visible symptom that follows from all this. It found releases where the plugin's own directory page and the metadata API behind the "View details" popup both showed the fixed version while the update-check API was still handing out the vulnerable one. If you have ever looked at a changelog, seen the fix you were waiting for, gone back to wp-admin and found no update offered, that is the mechanism, not a caching bug on your side.

Important: If you script version checks for a fleet of sites, check what your script actually reads. A check against the plugin directory page or the plugin information API will report a version your sites cannot install yet through the normal path.

What the automated review does not cover

Four gaps are worth being explicit about, because a headline about WordPress blocking dangerous updates reads to a lot of site owners like the plugin problem has been handled.

Code that is already installed. The check evaluates a release on its way out. It has no view of what is running on your server. A plugin you installed in 2023 that has a vulnerability disclosed tomorrow is unaffected by any of this, and so is a plugin that was removed from the directory while you kept running it.

Plugins that do not update through wordpress.org. This is the significant one for commercial sites. Premium plugins and extensions bought from a vendor or a marketplace check for updates against their own servers and download from their own infrastructure. Nothing in the WordPress.org pipeline touches them. A typical WooCommerce store runs several, and they are often the ones closest to money and customer data: payment gateways, shipping integrations, subscription handling. If you maintain sites for clients, the practical exercise is to list which of your plugins update from outside the directory, because that list is now the part of your stack with no pre-distribution review at all.

Anything installed by hand. A ZIP uploaded through the admin, a plugin dropped in over SFTP, a client's own functionality plugin, code in mu-plugins. None of it passes a review step, and in most long-lived sites this is where the oldest, least examined code lives.

Problems that are not in the code. An administrator account without two-factor, an over-permissive API key committed to a repository, a stale SFTP credential. The most common way sites get compromised has never been a backdoored release.

There is also an open question on themes. The cooldown has covered plugin and theme releases since June, but the September announcement describes the automated review and the automatic block specifically for plugin releases. Whether theme releases get the same scoring and blocking treatment is not stated either way, so treat it as unconfirmed rather than assuming parity.

Does this make plugin updates safe now?

No, and the reason is more interesting than the answer.

The gate does one job well: it puts distance between a malicious or badly broken release and mass distribution. That is exactly the right response to supply-chain attacks, where the attacker's advantage is that the update mechanism is trusted and automatic.

Against the other main threat, it works against you. When a vulnerability is publicly disclosed and a fix ships, the attacker's clock starts at disclosure and yours starts when your site can actually install the patch. The cooldown sits between the two. Patchstack's 2026 security report puts the median time to mass exploitation of heavily exploited vulnerabilities at around five hours, and in one WordPress core case it recorded exploitation attempts starting about 90 minutes after the patched version was released. A six-hour hold is longer than either of those windows.

Patchstack's measurements over a 17-day sample found that security releases got no different treatment from routine ones. It counted 81 releases patching a disclosed CVE moving through the delay, across 79 distinct plugins with a combined install base of roughly 9.9 million. Thirty of those fixes were rated CVSS 7.0 or higher and nine were 9.0 or higher, including one rated 10.0. A patch for an arbitrary file deletion flaw waited the same length of time as a release that changed a translation string.

Combined install counts are not the same as vulnerable sites, and the same research found no evidence of active exploitation during the specific windows it watched. But the structural point stands and is not really disputed: one clock is doing two jobs, and it is only suited to one of them. The fix is an expedited path for confirmed vulnerability fixes, which WordPress.org has not announced.

There is a draft proposal to let a release skip the remaining cooldown when the automated scan finishes with no findings, which would cut the delay for most releases to however long the scan takes. It is a proposal, not an implemented change, and it also removes the human-review portion of the window for anything the scanner clears. If it lands, the gap in this article's arithmetic mostly closes.

What site owners and agencies should actually do

Almost nothing here argues for turning auto-updates off. The six-hour hold is not a reason to stop updating, and the sites that get compromised are overwhelmingly the ones running versions that are months behind, not hours.

Stop treating the update screen as your vulnerability feed. It was already a weak signal and it now lags the disclosure by design. If you manage more than a handful of sites, subscribe to a vulnerability feed and drive your urgency from that, then use the update screen to carry out the work.

Know what you are actually running. Before you decide whether an advisory applies, check the installed versions rather than the update list:

wp plugin list --fields=name,status,version,update_version

If you need to force WordPress to re-query the update API instead of using its cached answer, clear the stored result first:

wp transient delete update_plugins --network
wp plugin list --update=available

Verify files against the directory when something feels wrong. WP-CLI can compare installed plugin files against the checksums wordpress.org holds, which is the fastest way to spot a plugin whose files have been altered on your server:

wp plugin verify-checksums --all

This only covers plugins hosted in the directory, and a plugin that has been closed may not return usable checksums. It is a triage tool, not a malware scanner.

Understand the bypass before you use it. Because the ZIP is downloadable as soon as the version is tagged, deleting a plugin and reinstalling it, or installing a specific version directly, has been reported to skip the wait entirely:

wp plugin install example-plugin --version=1.2.3 --force

Two things to be clear about. First, this behaviour is a side effect of where the gate sits, not a documented feature, and it could be closed at any time. Second, using it means you are taking a release that has not finished its security review, which is the precise protection the cooldown exists to provide. That trade can be right during an actively exploited disclosure and is hard to justify for a routine update. If you do it, do it on staging first, and read the diff between the two versions if you can.

Keep a restore point that predates the update. Whatever process you use, the thing that reliably saves a site is being able to go back. On MagicWP, daily off-site backups with one-click restore and on-demand backups before a change are part of the platform, and one-click staging means testing an urgent patch against a copy of the real site takes minutes rather than an afternoon. Core updates are a separate matter: they are not held by this cooldown, and MagicWP applies them automatically with rollback.

Audit your out-of-directory plugins once. Write the list down. For each one, note where it updates from and whether the vendor publishes security advisories. That list is now the part of your plugin stack with the least oversight, and on a WooCommerce site it usually includes the most sensitive code you run. If you want the platform-level context for how the rest of that stack is protected, MagicWP's security features cover the WAF, malware scanning and container isolation side of it.

What plugin developers should change

If you publish to the directory, the practical question is how to keep releases from getting blocked in the first place, since publishing a fixed release is almost always faster than waiting for a manual review of an appeal.

In the discussion under the announcement, the Plugins Team pointed at the patterns that most often push a score up. They are the ordinary vulnerability classes rather than anything exotic:

• REST, AJAX or admin-post endpoints without a capability check. A nonce proves the request came from your form. It does not prove the sender is allowed to do the thing.
• Database queries built without $wpdb->prepare().
• File paths, uploads, deletions or includes built from request data.
• unserialize() called on request data or on a remote response.
• Options, user meta or settings written from endpoints that a subscriber or an unauthenticated visitor can reach.
• Code fetched or evaluated at runtime, and anything obfuscated or packed.

The last one is worth a note for honest developers: packed or minified PHP, dynamic includes and runtime-fetched code look the same to a scanner as a backdoor does. If your build process produces any of that, expect friction.

The tooling recommended by the team runs in roughly this order of payoff. PHP_CodeSniffer with the WordPress Coding Standards, where the WordPress-Extra ruleset includes the security sniffs covering output escaping, input validation and nonce verification:

composer require --dev wp-coding-standards/wpcs
vendor/bin/phpcs --standard=WordPress-Extra path/to/plugin

Then Plugin Check, which the Plugins Team has been running automatically against new plugin versions since October 2025 and which you can run yourself locally or in CI:

wp plugin check example-plugin

Then static analysis that follows data flow across files, such as PHPStan with the WordPress extension or Semgrep with WordPress rules. This is the category that catches the findings a rule-based sniffer cannot see, where user input reaches a dangerous function several files away from where it entered. If you publish WooCommerce extensions, QIT includes security scans alongside its compatibility runs.

None of this replaces a second pair of human eyes on the diff before you tag. The most common real finding is not malicious code at all. It is an endpoint written for an admin screen that turned out to be reachable by anyone.

On release planning, build the hold into your schedule. If you tag a release at the end of your working day, the distribution starts hours later, and a blocked release means the fix and the new tag both land the next day. For a security release, that is a materially different situation from what developers were used to before June.

Frequently asked questions

Does the six-hour cooldown apply to WordPress core updates?

No. Core releases go through the core release process and are not held by this cooldown. That distinction matters during an incident: if a core vulnerability is patched, sites with automatic core updates enabled can receive the fix without waiting on the plugin directory's clock. MagicWP applies core updates automatically with rollback for exactly this reason.

Why does my dashboard show no update when the plugin page shows a newer version?

Because the plugin's directory page and the update-check API are served from different points in the release pipeline. The page reflects the tagged version straight away, while the update API waits out the cooldown and any security review. Unless the cooldown has expired and the release has cleared its review, wp-admin will keep showing the older version. Clearing the update_plugins transient will not change that, since it only forces a fresh query against the same gated API.

Can I tell whether a specific release has been blocked?

Not from your site. The findings email goes to the plugin's committers, not to users, and WordPress.org does not publish a list of blocked releases. From the outside, a blocked release looks the same as a release still inside its cooldown: the version is tagged, and your dashboard never offers it. If a release you are expecting stays unavailable well beyond the usual window, that is the signal to check the plugin's support forum or the developer's own channels.

Should I disable auto-updates because of the delay?

No. The delay affects when a patch reaches you by a matter of hours. Disabling auto-updates affects whether it reaches you at all, and the gap between "patched six hours late" and "patched six months late" is where nearly all real compromises live. If you need faster patching than the cooldown allows for a specific high-severity disclosure, the answer is a controlled manual intervention on that one plugin, not turning the mechanism off across a fleet.

Does this protect my premium plugins?

No. Plugins that check for updates against a vendor's own servers are entirely outside the WordPress.org pipeline. They get no cooldown, no automated security review, and no block. For most commercial WordPress sites this is the larger share of risk, because premium extensions tend to sit closest to payments and customer data.

What happens to a plugin author whose legitimate release gets blocked?

They receive an email listing the findings that triggered the block, and the release does not go out through the update API until the issues are resolved. The advised route is to review the findings, fix them, and publish a new release, since a corrected release moves faster than an appeal. Authors can contact the Plugins Team if a finding looks wrong, but the team handles a high volume of reviews and the appeal path is slower.

Does a high security score mean the plugin is malicious?

No, and the Plugins Team has been explicit about this. The score reflects the security impact and the likelihood of abuse, not the developer's intent. An unintentional missing capability check can score the same as a deliberately planted backdoor, because from the perspective of an attacker they offer the same opportunity.

Conclusion

The WordPress automated plugin security review closes a gap that has been open since the directory existed: there was no consistent check between a developer committing a release and that release reaching millions of sites. It now runs on every plugin release, it blocks high-risk ones without waiting for a human, and it has one documented save behind it. That is a genuine improvement to the ecosystem and it deserves to be described as one.

It is also narrow, and the narrowness is the part worth acting on. The check covers directory-hosted plugin releases on their way out. Your premium plugins, your hand-installed ZIPs, your client's custom functionality plugin and every line of code already running on your server sit outside it. And because the same clock holds a critical security patch and a routine release for the same six hours, the one thing this change does not do is make you faster during a disclosure. Build your urgency from a vulnerability feed, keep a restore point that predates every update, and test anything you rush on a copy of the real site first. On MagicWP, on-demand backups before a change and one-click staging are there so the careful version of that process is the convenient one too.

One last practical note: every specific number in this article, from the length of the cooldown to the scope of the block, is an operational setting that WordPress.org has already changed once without a public announcement. Check the Make WordPress Plugins blog before you plan a release schedule or a patching policy around any of them.