I committed a new version of my plugin to SVN and got a message I hadn’t seen before: this version will reach sites in about 24 hours. My first thought was that I’d broken something. I hadn’t. What changed isn’t on my side at all. The system that distributes my plugin stopped trusting my commit by default, and the more I sat with that, the more I agreed with it.

Here’s the part that matters, and it isn’t “updates are slower now.”

The hold, in one line

Since June 5, 2026, WordPress.org holds new plugin and theme releases for up to 24 hours before they go out through auto-update. The plugin page flips to the new version immediately, and the zip is already the new build. What’s paused is only the update notification and the auto-update pipeline reaching live sites. Manual updates from the dashboard still apply instantly. So the directory shows the new version while every site’s admin still shows the old one, for up to a day.

That gap is harmless. The reason a checkpoint had to exist is the actual story.

The trust that broke

Plugin distribution ran for years on one quiet assumption: whoever holds SVN commit access is trusted, so whatever they commit can go straight to every user. The whole pipeline sat on top of that.

In April 2026 the assumption broke. Thirty-one plugins under one brand were pulled from the directory at once because every one of them carried a backdoor, with reporting putting the blast radius at up to 400,000 sites. The ugly part: the attackers didn’t hack anyone. They bought the plugins. They acquired them outright, inherited legitimate SVN commit access, and shipped malware as a normal update. Around 191 lines, folded into a single release dressed up as a compatibility patch, dormant for months before doing anything. The legitimate distribution channel became the delivery route. Not stealing the key, but buying it.

Run that against the old assumption and it collapses. “The person with commit access is trusted” holds right up until commit access is bought by someone who isn’t. And no amount of care on the author’s side helps, because once the commit rights themselves change hands, author-side defense was never the layer that mattered.

Why the check can only live on the distribution side

So the answer was to stop trusting authors individually and inspect every release before it ships. On June 5, 2026, the opt-in 24-hour delay became a default across all 61,000-plus plugins in the directory, part of an effort named Protect The Shire, with the held time going to moderators and security scanners reviewing changes before delivery.

Think about where else that check could possibly sit. Ask an author “is your commit safe?” and a malicious author says yes. The people behind the bought plugins followed every legitimate step legitimately. As long as safety leans on the author’s own word, a purchased author walks straight through. The only place to inspect everyone is the layer they all pass through on the way out. It isn’t that authors are presumed guilty; it’s that trusting authors can no longer guarantee anything.

The trust boundary moved one step out

I’ve written before that AI-generated code should be treated as untrusted external input: don’t believe the model’s output, sanitize it, suspect it before you use it. That’s drawing a trust boundary inside your own code.

This change moved the same boundary one step further out. What used to sit inside the trusted zone, the author’s own commit, is now on the untrusted-input side from the distributor’s view. Not just the model’s output, but a human author’s commit, gets treated as suspect until it clears review. The default trust level dropped another notch, from inside to outside.

I can sign on to that partly because I’ve distrusted my own code before. A self-review of one of my plugins turned up 35 issues I’d written myself and was about to ship. Code deserves to be doubted before it goes out, mine included. A distribution layer that suspects every author is suspecting me too, and that feels correct, not insulting.

The other face of 24 hours

There’s a cost, so I’ll name it. Patchstack’s 2026 data puts roughly half of high-impact WordPress vulnerabilities under active exploitation within 24 hours of disclosure. The same shield that stops a malicious release before it ships also delays a legitimate security patch reaching sites automatically by exactly as long. The wall and the shield are the same object.

For urgent fixes there’s a path to request faster delivery, and authors can point users to a manual update in the meantime, since the zip is already published during the hold. But the tension doesn’t vanish. The 24 hours that protect against a poisoned release are the same 24 hours a real fix stays undelivered. I still take the world where everyone clears a checkpoint over the world where a bought author ships malware down the legitimate pipe.

What I’m taking from it

Read the hold as “distribution got slower” and you miss it. The default trust of distribution dropped. “Commit access means trusted” broke the moment access could be purchased, so authors stopped being trusted individually and every release now passes a check. My commits are in that line too.

Being distrusted by default isn’t flattering. But as someone who found 35 holes in his own code, the distrusting default is probably the right one. The distribution side now looks at a human author’s commit the way I’ve learned to look at a model’s output: as input to verify, not output to trust. I’m inside that gaze now, and I’d rather call it correct than take it personally. That 24 hours is time my plugin’s users are being protected.

Originally written in Japanese on Zenn. I build WordPress plugins and write about Claude Code, web security, and plugin development.