WordPress.org Adds 24-Hour Delay for All Plugin Updates Afte

WordPress.org Adds 24-Hour Delay for All Plugin Updates After Supply Chain Attack

Starting June 5, 2026, WordPress.org now holds all plugin updates for 24 hours before distribution. The change follows the Essential Plugin incident where 31 plugins were bought and backdoored via legitimate SVN commits, affecting up to 400,000 sites.

4 min readJun 13, 2026

WordPress.org Adds 24-Hour Delay for All Plugin Updates After Supply Chain Attack

The 24-Hour Hold Is Now Default

On June 5, 2026, WordPress.org made the 24-hour release delay mandatory for all 61,000+ plugins in the official directory. Previously opt-in since August 2025, the delay is now the default for every plugin update. When you commit a new version to SVN, you'll see: "This version will be delivered to sites in approximately 24 hours."

What Actually Gets Delayed?

Only the automatic update pipeline is held back. The plugin page on WordPress.org updates immediately — the zip file is swapped, the version number changes. What stops is the notification that appears in wp-admin and the actual file delivery to sites. This creates a window where the directory shows a new version but no site has received it yet.

Why the Change? The Essential Plugin Attack

On April 7, 2026, 31 plugins under the "Essential Plugin" brand were removed from the directory. All contained backdoors. Attackers didn't hack anything — they bought the plugins on Flippa, gaining legitimate SVN commit access. Then, through a normal update, they injected 191 lines of malicious code disguised as a compatibility patch. The code lay dormant for 8 months before activating. Estimated impact: up to 400,000 sites.

This is a textbook supply chain attack. The old trust model — "committers are trustworthy" — collapsed when committers could be bought. You can't ask a malicious author "is your commit safe?" and expect an honest answer. The only place to put security checks is on the distribution side, before delivery.

How the 24-Hour Window Works

During the 24-hour hold, WordPress.org runs automated security scanners and human moderators review the changes. The plugin team announced in early 2026 that they had enhanced their internal scanner with AI-assisted checks and multiple automated tests. This automation made it feasible to review 61,000 plugins uniformly.

Ironically, AI is both the problem and the solution. Generative AI makes it easier to produce malicious plugins at scale, increasing the volume of submissions. But AI also powers the defense — machines now pre-screen submissions so human reviewers can focus on suspicious cases.

The Cost of the Shield

The 24-hour delay is a double-edged sword. According to a 2026 Patchstack survey, roughly half of impactful WordPress vulnerabilities are exploited within 24 hours of disclosure. So the same delay that blocks malicious updates also delays critical security patches. WordPress.org provides an escalation path for urgent fixes, but the trade-off is real: every hour a legitimate patch is delayed, sites remain exposed.

What This Means for Plugin Authors

Your commits are now treated as untrusted input until verified. This isn't a personal judgment — it's a structural response to a broken trust model. The author's own experience mirrors this: they once found 35 issues in their own plugin during a self-review. Code should be doubted before shipping.

If you're a plugin author, expect to see the 24-hour message on every commit. Plan your release schedule accordingly. For critical security fixes, use the emergency contact channel to request expedited review. The new normal is: "Your update is safe, but we'll verify that ourselves."

The Bigger Picture

This move shifts the trust boundary outward. Previously, "trust but verify" applied to user input and AI-generated code. Now, even human-authored commits from verified accounts are considered untrusted until scanned. The initial trust value has been lowered for everyone.

As the author puts it: "The 24 hours is time your plugin's users are being protected." That's the perspective to hold onto when your next commit gets stuck in the queue.

Key Technical Details

Date of change: June 5, 2026
Trigger event: Essential Plugin backdoor, April 7, 2026
Affected plugins: 31 removed, up to 400,000 sites impacted
Malicious code: 191 lines, dormant for 8 months
New default: 24-hour delay for all 61,000+ plugins
Previous state: Opt-in delay since August 2025
Emergency path: Available for urgent security fixes

Editor's Take

I've been burned by rushed plugin updates before, so I actually welcome this change. The Essential Plugin attack shows that trusting commit access alone is naive — buying a plugin is cheaper than hacking it. My only concern is the 24-hour delay for genuine security fixes. WordPress.org needs to make the emergency path fast and reliable, or they'll trade one risk for another. I'd rather wait a day for a feature update than have malware auto-installed on my clients' sites.

— DevDigest Editorial

Key Takeaways

•Plan releases to account for the 24-hour delay; don't commit a security fix at 5 PM on Friday.
•Use the emergency escalation channel for urgent patches — verify the process works before you need it.
•Review your plugin's SVN access control; consider who could gain commit access if your account or business is compromised.

Why It Matters

If you maintain a WordPress plugin, your updates now face a mandatory 24-hour delay before reaching users. This changes how you handle security patches and release planning. The underlying supply chain attack vector — buying plugins to inject backdoors — is a warning for any platform with delegated commit access.

#supply-chain-security#wordpress#plugin-development#SVN#WordPress.org

Get the weekly digest

Every Sunday - top tech stories, industry breakthroughs, and developer tools delivered to your inbox.

No spam, unsubscribe anytime.