WordPress Now Screens Every Plugin Update Before You Get It (2026)

The Short Version

WordPress.org now runs an automated security review on every plugin release before it can reach your site, and it blocks a release outright if the risk score comes back high. On July 28, 2026, that screening caught a backdoor in a plugin with roughly 20,000 active installs, and the compromised version never shipped. You do not have to change anything on your site. The update that would have hurt you simply never arrived.

This is the biggest change to how plugin updates work since automatic updates became the norm. Here is what actually changed, how the screening works, and what it means for the plugins you already run.

Why This Exists: The Gap Nobody Was Watching

New plugins have always been reviewed before they enter the WordPress.org directory. The problem was everything after that. Once a plugin was approved, every future release shipped straight out to users with no consistent review step between the commit and the download.

David Perez, co-lead of the WordPress Official Plugin Repository Team, put it plainly: a plugin can be secure today and introduce a vulnerability, or malicious code, in a future release. That is the gap attackers use. Compromise one maintainer account, push a clean-looking update, and it lands on tens of thousands of sites before anyone notices.

That gap is now covered, at least for plugins distributed through WordPress.org.

A Backdoor That Never Made It Out

On July 28, 2026, the automated review flagged a backdoor that had been committed to a release of a plugin with about 20,000 active installations. Because the release was still inside the cooldown window, the compromised version never went out through the official update API.

WordPress security company Wordfence alerted the Plugins Team, and the plugin was closed for downloads 26 minutes later. WordPress has not named the plugin, which is fair: the update never reached users, so there is nothing for site owners to clean up.

The important part is not the plugin. It is that the system did exactly what it was built to do, on a real attack, without anyone having to notice it first.

How the Screening Actually Works

The foundation is a program called Protect The Shire. Since June 5, 2026, every plugin and theme release waits in a cooldown period before it can be distributed through auto-updates. The cooldown started at 24 hours and now sits at 6. The thinking is simple: add friction so a malicious update cannot reach the whole internet in a few seconds.

During that cooldown, the release is now analyzed in two ways:

• AI models review the changes in the release.
• Jetpack Scan runs its own checks on the same code.

The two results are cross-verified and combined into a single security score. A high score means higher risk. If a release lands above the threshold, it is blocked automatically, with no human reviewer in the loop. If it scores below the threshold, it continues through the normal cooldown and ships as usual.

Developers only hear about it when something is blocked. The committer gets an email with the findings. To get the restriction lifted, they review the issues, fix them, and publish a new release. If the new release scores below the threshold, it flows normally. Appeals to the Plugins Team exist, but Perez notes that shipping a fixed release is almost always faster than waiting on a manual review.

One caveat straight from the announcement: a high risk score does not mean a developer turned malicious. Accidentally introduced security flaws raise the score exactly like intentional malware does. The score measures risk, not intent.

What Pushes a Release Into the High-Risk Zone

WordPress has quietly published the patterns that drive a release’s risk score up. If you maintain a plugin or theme, this is the list to code against:

• REST, AJAX, or admin-post endpoints with no capability check. A nonce is not authorization.
• 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 a subscriber or logged-out user can reach.
• Code fetched or evaluated at runtime, plus obfuscated or packed code.

Perez’s own advice is the least glamorous and most effective fix: follow the WordPress Coding Standards and run PHP_CodeSniffer against your code. Developers publishing WooCommerce extensions are pointed at the Quality Insights Toolkit (QIT) for the same reason. Most of what the scanner flags is the kind of thing a linter would have caught first.

What This Means If You Just Run a Site

Practically nothing changes in your dashboard. Updates still show up, auto-updates still run, and you still click Update when prompted. What changed is what reaches you in the first place.

A few things worth knowing:

• A “missing” update can now mean a blocked update. The email goes to the developer, not to you. If a plugin you rely on suddenly shows no update when you expect one, this is one possible reason.
• Updates can lag by up to six hours. That delay is the feature. It is the window where the screening happens.
• This is a reason to keep auto-updates on, not off. The vetting is exactly what you always wanted automatic updates to have.
• Do not treat it as a substitute for the basics. Two-factor on your admin accounts, daily backups, and a security plugin for the application layer are still on you. WordPress.org screens plugins. It does not secure your site.

If you manage client sites, the practical change is quieter mornings. Fewer tickets that trace back to a bad Tuesday update.

user@host:~$ wp plugin list --update=available --fields=name,version,update_version,status

name              version  update_version  status
woocommerce       9.9.1    9.9.2           active
contact-form-7    6.1      6.1.1           active
wordpress-seo     25.4     25.5            active

What This Means If You Build Plugins or Themes

Your release process now has an invisible reviewer, and its standards are public. Three things to internalize:

• Capability checks are not optional. Every endpoint you expose needs one. A nonce proves intent, not permission.
• Sanitize on the way in, escape on the way out. Prepared queries, validated file paths, and no unserialize() on anything a user can influence.
• Treat the cooldown as part of your launch timing. A release is not live the second you push it. Plan urgent hotfixes with that delay in mind.

A blocked release is a delay, not a ban. Fix the finding, ship a new version, and it goes through the same path as everything else.

Three Things This Does Not Fix

It is a real improvement, and it is not a force field. Be clear about the edges:

• Plugins that did not come from WordPress.org. Premium plugins from marketplaces, custom code, and anything from a nulled-download site never pass through this pipeline. Those are on you, and they remain one of the most common routes into a hacked site.
• A compromised maintainer account pushing clean code. If an attacker steals valid credentials and commits an update that looks legitimate, the scan can pass it. Turn on two-factor for your WordPress.org account.
• Everything on the site itself. The review protects the supply chain, not your configuration, your passwords, or your backups. That layer is still the one you own.

If your site has already been compromised, or it keeps getting hit, the plugin pipeline is not where you fix it. Start from the recovery side instead. Our full walkthrough covers what to do when WordPress gets hacked, and if you run a store, the WooCommerce security guide covers the checkout and payment side.

The Questions Everyone Asks

Final Thoughts

For years, the advice for WordPress security ended with “just keep your plugins updated.” That advice quietly assumed the updates themselves were trustworthy. As of September 2026, WordPress.org is doing real work to make that assumption true, and the July backdoor catch is the proof that it can work.

So keep updating. Keep auto-updates on. And keep doing the unglamorous things too: strong passwords, two-factor, and backups, because a supply chain that vets itself is a safety net, not a substitute for basic hygiene.

Disclosure: this post contains an affiliate link. If you buy through it, we may earn a commission at no extra cost to you.

About The Author

Marcus Li

Marcus Li is a web designer and marketing specialist based in Vancouver, BC. After years of helping clients build their online presence, he discovered how AI tools could level the playing field for everyday entrepreneurs. He shares what actually works, no fluff, no hype.

See author's posts