---
title: "WordPress.org Now Reviews Every Plugin Release: What The New Automated Security Check Catches And What It Misses"
url: https://nexterwp.com/blog/wordpress-plugin-security-review/
date: 2026-10-02
modified: 2026-10-02
lang: en
author: "Aditya Sharma"
description: "WordPress.org now runs an automated security review on every plugin release before it reaches your dashboard. Here is what it checks, what it cannot see, and what I would still do."
image: https://nexterwp.com/wp-content/uploads/2026/10/wordpress-plugin-security-review-featured-1024x538.png
word_count: 2767
---

# WordPress.org Now Reviews Every Plugin Release: What The New Automated Security Check Catches And What It Misses

## Key Takeaways

- WordPress.org now analyses every plugin release during a cooldown window before it reaches the update screen, and the current wait is 6 hours.
- Plugins Team says a high-risk release is blocked automatically, and the July 28 backdoor in a plugin with around 20,000 active installations never reaches sites.
- The automated review uses several AI models together with Jetpack Scan, then cross-checks the results into a security score.
- A score measures risk, not intent, so an accidentally introduced vulnerability can score as high as deliberate malware.
- The review covers plugins hosted in the official directory, but it does not certify old versions, abandoned plugins, or premium code kept outside the repository.

 

On September 9, 2026, the WordPress.org Plugins Team published a short post with a large consequence: every plugin release is now analysed for security problems before it can reach the update screen on your dashboard. I read that announcement, the earlier WordPress.org news post that set up the waiting period it depends on, the trade press coverage, and the Reddit thread where plugin developers argued about it.

The headline is good news. A release that scores as high risk is blocked automatically, and the Plugins Team says that already stopped a backdoored release from reaching sites. But the headline also invites a lazy conclusion, which is that plugins from the directory are now safe by default. They are safer. They are not safe by default, and the gaps matter if you run a real site.

This post explains what changed and when, how the review works, what it can and cannot see, and the short list of habits I would keep on my own sites. Where I am relying on a source, I say which one. Where I am giving an opinion, I say that too.

Table of Contents

## What WordPress.org Changed And When

There are two separate changes, and they are easy to blur together. The first is a waiting period. The second is the automated review that runs inside it.

The waiting period came first. In a June 2026 news post titled [To Update or Not](https://wordpress.org/news/2026/06/pts/), WordPress.org described a tension between updating fast to stay secure and holding back to stay secure. It pointed to supply chain attacks across other ecosystems and to its own incident, in which plugins were sold to a new owner who then planted a backdoor. The post also gave scale: more than 78,000 plugins and themes in the directory, over 400 million installs in total, and more than 3,000 commits to the plugin repository in a single day.

![WordPress.org news post To Update Or Not about the plugin release cooldown](https://nexterwp.com/wp-content/uploads/2026/10/wordpress-org-to-update-or-not-plugin-cooldown.webp)The June 2026 WordPress.org news post that introduced the cooldown before plugin and theme releases are distributed.

The same post said each new release would wait up to 24 hours before being distributed through auto-updates, and that the team expected the wait to shrink as the process matured. The Plugins Team post I read in September says the cooldown has applied to every plugin and theme release since June 5 and is currently set to 6 hours. So the wait has already come down from the figure first described.

The review is the second change. During that cooldown, the changes in each release are analysed, and the Plugins Team announced on September 9 that the process now covers every plugin release.

| Date (2026) | What happened | Source |
| ----------- | ------------- | ------ |
| June 5 | Cooldown begins for plugin and theme releases before distribution through the update API | Plugins Team post |
| June | WordPress.org news post describes the cooldown and the supply chain risk behind it | WordPress.org news |
| July 28 | A backdoor is committed to a release of a plugin with around 20,000 active installs and is caught during the cooldown | Plugins Team post |
| September 9 | Automated security review announced for every plugin release | Plugins Team post |
| September 14 | The Hacker News covers the change | The Hacker News |
Timeline built from the Plugins Team post and the WordPress.org news post, both read on October 2, 2026.

![WordPress.org Plugins Team post announcing the automated security review for plugin releases](https://nexterwp.com/wp-content/uploads/2026/10/wordpress-plugin-security-review-plugins-team-announcement.webp)The Plugins Team announcement of September 9, 2026, published on make.wordpress.org.

## How The Automated Review Works

The Plugins Team post is short and specific, so I will keep to what it says. Before a release is distributed through the WordPress.org update API, its changes are analysed by several AI models working together with Jetpack Scan. The results are cross-checked and combined into findings with a security score. The higher the score, the higher the potential risk.

- A developer commits a release to the plugin repository.

- The release enters the cooldown, currently 6 hours, and is not offered to sites yet.

- During the cooldown the changes are analysed and scored.

- A release with a high risk score is blocked automatically as soon as the review finishes, and every plugin committer is emailed the findings.

- A release below the blocking threshold continues through the normal process and is distributed after the cooldown.

Two details in the post change how I read it. First, a high score measures risk, not intent. An accidentally introduced vulnerability can score as high as deliberate malware, so a blocked release is not an accusation. Second, emails go out only when a release is blocked, which means a developer who hears nothing has nothing to do, and also that nobody outside the team sees the clean results.

The team also says that cross-checking several tools keeps accuracy high and false positives low, but not at zero. That is an honest sentence, and it is the reason the post tells authors that publishing a fixed release is almost always faster than waiting for a manual appeal.

## The July 28 Backdoor Is The Case For The System

The most persuasive part of the announcement is a real incident. On July 28 a backdoor was committed to a release of a plugin with around 20,000 active installations. According to the post, the automated review detected it and assigned a high security score. Because the release was still inside the cooldown window, the compromised version was never distributed through the update API. The plugin was closed for downloads 26 minutes after the Plugins Team was notified by Wordfence about the update.

Read that sequence carefully, because it shows why the two changes belong together. The review alone would have produced a score and an email. The cooldown is what turned the score into protection, since it gave the review time to finish before any site received the file. The team also says the incident exposed a gap: a high-risk result should stop distribution automatically, without depending on someone from the Plugins Team being awake. That is what shipped on September 9.

![The Hacker News article on WordPress adding automated plugin reviews to block high-risk updates](https://nexterwp.com/wp-content/uploads/2026/10/hacker-news-wordpress-automated-plugin-reviews.webp)The Hacker News covered the change on September 14, 2026, under the Web Security heading.

## What A Release Review Looks For

The announcement does not publish the scoring rules, and I would not expect it to. But a reply in the comment thread under the post gives a useful picture of what tends to push a score up. The reply is addressed to a plugin author who asked which tools to use. Its author is not shown in the page text I read, so treat it as guidance from the team's side of the table, not as policy.

The patterns it lists will be familiar to anyone who has read a vulnerability report. I have put them in a table with a plain explanation of why each one matters to a site owner.

| Pattern the reply lists | Why it matters on your site |
| ----------------------- | --------------------------- |
| REST, AJAX or admin-post endpoints with no capability check | Anyone who can reach the endpoint can use it. The reply notes that a nonce alone is not authorization, which is the mistake I see most often. |
| Database queries built without a prepared statement | User input can end up inside the query. |
| File paths, uploads, deletions or includes built from request data | A visitor may be able to read, overwrite or run files they should not touch. |
| Unserializing request data or a remote response | A classic route to code execution. |
| Options or user meta written from endpoints a subscriber or visitor can reach | A low-privilege account can change site behaviour. |
| Code fetched or evaluated at runtime, or obfuscated code | You cannot audit what the plugin will actually run. |
Patterns taken from a reply in the comments under the Plugins Team post, read on October 2, 2026. I have paraphrased them.

The same reply recommends tools plugin authors can run before they commit, including PHP_CodeSniffer with the WordPress Coding Standards, the Plugin Check tool, and static analysis that follows data flow. It also says most of what the team sees is not malicious code. It is an endpoint written for an admin screen that ended up reachable by anyone. I think that is the single most useful sentence for a site owner to remember, because it explains why a trustworthy author can still ship a risky release.

## What The Review Does Not Cover

This is the part the headlines skip. I can see five limits, and three of them come straight from the sources.

### It Applies To Plugins Hosted In The Directory

The coverage I read describes the review as applying to plugins hosted in the official directory. A commenter in the r/ProWordPress discussion put the consequence bluntly: most plugins with a paid version keep their premium code outside the repository, so that code is not reviewed by anyone at WordPress.org, and people assume it is. Another commenter in the same thread warned against a false sense of security. You can read the original [thread on Reddit](https://www.reddit.com/r/ProWordPress/comments/1whohz1/wordpress_is_adding_a_new_security_gate_to_every/). I agree with the point, with one caveat: I did not find any statement from WordPress.org about how it treats the free half of a plugin whose Pro half lives elsewhere.

### A Score Is Not A Verdict

False positives are not zero, and the score measures risk. That cuts both ways. A blocked release may be harmless, and a release that scores below the threshold is not certified clean.

### It Reviews New Releases, Not The Past

The review applies to releases going forward. A vulnerable version that is already installed on your site stays vulnerable until you update it, and the review does nothing about plugins that have been abandoned. If a plugin stopped receiving releases a year ago, there are no new releases to review.

### Themes Are Less Clear

The June cooldown covers plugins and themes. The September announcement talks about plugin releases. I did not find a statement that the AI review also covers themes, so I would not assume it does.

### Ownership Changes Are A Human Problem

The incident WordPress.org cites in its June post involved good plugins being sold to a new owner with bad intentions. A release review can flag suspicious code in the release, but it cannot tell you that a developer you trusted no longer owns the plugin. That one is still on you.

A commenter who says they scan the whole repository with their own tool claimed that detections ran under 0.3% on the public repository but between 5% and 10% in some batches of premium plugins. I cannot verify that, and I would not build any decision on it. I mention it only because it fits the direction of the argument above.

## What I Would Still Do On A Real Site

None of this means you should stop updating plugins. The cooldown and review make routine updates safer, and I would keep automatic updates on for plugins from authors I trust. These are the habits I would keep on top of that.

### 1. Read The Directory Page Like A Checklist

Before installing a plugin, open its WordPress.org page and look at four things: the last updated date, the active installation count, the tested up to version, and how quickly the author answers support threads. I did this today with [Spectra Legacy](https://wordpress.org/plugins/ultimate-addons-for-gutenberg/) as an example, because it is a large plugin that changed its status recently.

![WordPress.org plugin page showing version, last updated date and active installations](https://nexterwp.com/wp-content/uploads/2026/10/wordpress-org-plugin-page-version-installs-last-updated.webp)A directory page read on October 2, 2026. The signals I check first are the version, last updated date, active installs and tested up to version.

The page showed version 2.20.4, last updated four days earlier, more than a million active installations and tested up to WordPress 7.1.2. The changelog lists security fixes in 2.19.26 (May 4), 2.19.29 (June 30), 2.20.0 (July 14), 2.20.1 (July 31), 2.20.3 (August 26) and 2.20.4 (September 28). That is six security releases in under five months. I read that as a maintained plugin whose author responds to reports, not as a warning sign by itself. The practical point is different: a plugin that patches often only protects you if you actually install the updates. The page also says the plugin is now in maintenance mode with new features going to a separate plugin, which is the situation I wrote about in [how to move from Spectra Legacy to Nexter Blocks](https://nexterwp.com/blog/migrate-from-spectra-legacy/).

### 2. Keep Fewer Plugins

Every plugin is another author, another release process and another thing that can change hands. A review pipeline does not shrink your attack surface. Removing a plugin you no longer use does. I try to audit the plugin list a couple of times a year.

### 3. Treat Premium Plugins Separately

For anything you buy, ask the vendor three questions. Is there a published security contact? Is there a disclosure policy? Is there a public changelog that mentions security fixes? If a vendor cannot answer, that tells you something. I wrote a longer process in [how to vet a WordPress plugin before you install it](https://nexterwp.com/blog/how-to-vet-a-wordpress-plugin/).

![Nexter guide on how to vet a WordPress plugin before installing it](https://nexterwp.com/wp-content/uploads/2026/10/how-to-vet-a-wordpress-plugin-nexter-guide.webp)The vetting guide on nexterwp.com covers the checks the automated review does not do for you.

### 4. Watch For Ownership Changes

If a plugin you rely on has been quiet for a long time and then suddenly ships a release, look at who published it. Check the contributors list on the directory page and the author link. A change of owner is not proof of a problem, but it is the situation WordPress.org itself used as its warning example.

### 5. Add A Layer That Does Not Depend On Plugin Code

A review cannot protect you from a stolen password or a brute force run. Limiting login attempts, turning off the built-in file editor and removing unused accounts all reduce what an attacker can do after a plugin problem. Nexter Extension has settings for several of these, and I walked through them in [Nexter Extension login security](https://nexterwp.com/blog/nexter-extension-login-attempt-monitoring/) and in [the WordPress 7.1.2 hardening guide](https://nexterwp.com/blog/wordpress-7-1-2-security-update/). To be clear about the limit, these settings do not scan plugin code and would not stop a backdoored plugin from running. They narrow what happens around it.

### 6. Keep A Backup You Have Restored

A backup you have never restored is a hope, not a backup. After any incident, the first question is how fast you can get back to a known good state.

If you want the wider checklist, [the guide to the best WordPress security plugins](https://nexterwp.com/blog/best-wordpress-security-plugins/) compares dedicated tools for scanning and firewalls, which are the layers this announcement does not replace.

## Where Nexter Fits In This

I should be straightforward about our position. The free version of Nexter Extension is listed on WordPress.org, so its releases go through the same cooldown and review as every other directory plugin. That is a statement about the pipeline, not a security certificate. I have not seen any review output for our releases, because the team only emails authors when a release is blocked. If you want evidence of how we handle security, the changelog and the [August 2026 update](https://nexterwp.com/blog/august-2026-update/) describe the hardening work we shipped.

The more interesting question for site owners is the one that applies to every vendor, including us: does the author publish what they changed, and do they respond when someone reports a problem? That is something you can check yourself in a few minutes, and no automated system can do it for you.

## What Is Coming Next In WordPress Core

The plugin review is not the only security work in motion. The [Roadmap to 7.2](https://make.wordpress.org/core/2026/09/18/roadmap-to-7-2/) lists a sudo mode that would ask you to re-authenticate before sensitive actions, a Secrets API for storing credentials, a round of hardening for Application Passwords and continued work on how WordPress processes HTML. The roadmap is clear that these are being pursued and are not guaranteed to land in 7.2, which is due in early December 2026. I covered the full list in [WordPress 7.2: release date, Ipsum theme and every feature on the roadmap](https://nexterwp.com/blog/wordpress-7-2/).

## What This Doesn't Cover

- I did not test the review myself. I have no way to submit a release and see a score, so everything about how it works comes from the Plugins Team post.

- I could not confirm who wrote the comment I cite for the list of risky patterns, so I treat it as guidance and not policy.

- I did not verify the repository scan figures from the commenter. I flagged them as unverified in the text.

- I did not check whether the AI review also applies to themes. The sources I read describe plugin releases.

- I did not audit any particular plugin's code. The Spectra Legacy example only reads public directory data.

- I did not cover hosting level protection such as a web application firewall.

## Suggested Reading

- [How To Vet A WordPress Plugin Before You Install It](https://nexterwp.com/blog/how-to-vet-a-wordpress-plugin/)

- [Best WordPress Security Plugins](https://nexterwp.com/blog/best-wordpress-security-plugins/)

- [WordPress 7.1.1 And 7.1.2 Security Releases](https://nexterwp.com/blog/wordpress-7-1-2-security-update/)

- [MCP Security In WordPress](https://nexterwp.com/blog/mcp-security-wordpress/)

- [Nexter Extension Login Security](https://nexterwp.com/blog/nexter-extension-login-attempt-monitoring/)

If you want the hardening settings I mention above in one place, start with the [Nexter Extension](https://nexterwp.com/nexter-extension/) page.

[Explore Nexter Extension](https://nexterwp.com/nexter-extension/)

#### Stay updated with Helpful WordPress Tips, Insider Insights, and Exclusive Updates – Subscribe now to keep up with Everything Happening on WordPress!

Subscribe

## Frequently Asked Questions

**Q: Why are some WordPress plugin updates blocked before they reach my dashboard now?**
A: WordPress.org now analyses each plugin release during a cooldown window before it is distributed through the update API. If the release gets a high security score, it is blocked automatically. The point is to stop risky code before it reaches sites, not to declare every directory plugin safe. The system already caught a backdoored release on July 28, which is the clearest proof that the cooldown plus review can prevent a bad update from landing.

**Q: Does WordPress.org’s new security review cover premium plugins too?**
A: The review described in the post applies to plugins hosted in the official WordPress.org directory. That matters because many paid plugins keep their premium code outside the repository, so that code is not part of this pipeline. The practical takeaway is to treat free directory code and premium vendor code as separate risk buckets. For premium plugins, the page recommends checking for a published security contact, disclosure policy, and public changelog with security fixes.

**Q: What does WordPress.org’s automated plugin review actually look for?**
A: The review is looking for patterns that often lead to real vulnerabilities: endpoints without capability checks, database queries without prepared statements, file paths or uploads built from request data, unserialized input, low-privilege users changing site behavior, and code fetched or evaluated at runtime. The comment thread also notes that a nonce is not authorization. That matters because many risky releases are not malicious at all, just admin-only code that accidentally became reachable by subscribers or visitors.

**Q: Is a high security score from WordPress.org the same as a plugin being malicious?**
A: No. The score measures risk, not intent. A release can be blocked because it looks dangerous even if the author introduced the problem by accident. The reverse is also true: a release below the threshold is not certified clean. That distinction matters if you are triaging updates on a real site, because the system is designed to reduce exposure, not to give you a clean bill of health.

**Q: What should I still do on my site even with WordPress.org reviewing plugin releases?**
A: Keep updating, but do not rely on the review alone. The page recommends reading each directory listing like a checklist: last updated date, active installations, tested up to version, and support response speed. It also says to keep fewer plugins, watch for ownership changes, and keep a backup you have actually restored. For extra hardening around plugin risk, [Nexter Extension login security](https://nexterwp.com/blog/nexter-extension-login-attempt-monitoring/) and [the WordPress 7.1.2 hardening guide](https://nexterwp.com/blog/wordpress-7-1-2-security-update/) add controls that limit damage after an incident.

**Q: How should I judge whether a WordPress plugin is still safe to use?**
A: Look at maintenance signals instead of assuming old equals bad or new equals safe. The page uses Spectra Legacy as an example: version 2.20.4 was updated four days earlier, had more than a million active installations, was tested up to WordPress 7.1.2, and had six security releases in under five months. That reads like an actively maintained plugin that responds to issues. If you want a deeper process for this kind of check, [How To Vet A WordPress Plugin Before You Install It](https://nexterwp.com/blog/how-to-vet-a-wordpress-plugin/) lays out the same kind of pre-install review.