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.
Top comments (16)
The most dangerous attacks are often the ones that follow every rule.
No stolen accounts. No zero-days. No infrastructure compromise. Just a legitimate ownership transfer followed by a legitimate release process.
That’s why modern security isn’t about trusting people more carefully. It’s about designing systems that remain safe even when trusted actors change. The 24-hour review window is less about malware detection and more about acknowledging that trust itself is a mutable asset.
Exactly. "Trust as a mutable asset" is a sharper way to put what I was circling around. The part that stayed with me is that the only place to act on that mutability is the gate, not the actor. You can't ask an actor to flag the moment their own trust changed hands, so you stop trusting the actor and verify the artifact instead.
That’s a great point.
What strikes me is that mature systems eventually stop asking “Who produced this?” and start asking “What evidence do we have that this is safe?” Identity remains important, but it’s no longer sufficient. The more valuable the supply chain becomes, the more verification shifts from actor-based trust to artifact-based trust.
That's the shift, yeah. "What evidence do we have that this is safe?" is exactly where I landed, and it's why I can sit with my own commits being held. I trust myself the least usefully of anyone, a self-review once surfaced 35 issues I'd written, so artifact-based verification checking me too feels right, not insulting. Identity gets you in the door; the evidence is what actually ships.
“Identity gets you in the door; evidence is what ships” is probably the best summary of modern security I’ve heard in a while.The interesting part is that this principle scales remarkably well. Whether the producer is a maintainer, a vendor, an employee, or an AI model, the question eventually converges to the same thing:
What evidence do we have that this artifact is safe?
That's the shift, yeah. "What evidence do we have that this is safe?" is exactly where I landed, and it's why I can sit with my own commits being held. I trust myself the least usefully of anyone, a self-review once surfaced 35 issues I'd written, so artifact-based verification checking me too feels right, not insulting. Identity gets you in the door; the evidence is what actually ships.
Default distrust feels annoying until you remember how much supply-chain trust is sitting behind a plugin update. For ecosystems like WordPress, the commit path is effectively a distribution channel, not just source control.
The healthy version is not "make every author suffer"; it is making provenance and review visible enough that maintainers can prove a release deserves trust. Friction is acceptable when it protects users from invisible compromise.
You sharpened the part I left implicit. The commit path being a distribution channel and not just source control is the whole reason the old "committer is trusted" assumption was load-bearing in a place nobody was looking.
And your reframe is the one I'd adopt: the healthy version isn't punishing authors, it's making provenance and review visible enough that a release can prove it deserves trust. That flips the default from "trust me" to "here's why this is verifiable," which is a better place for everyone to stand, me included. Distrust-by-default is only the blunt first move. Provability is the part that makes the friction worth paying, because friction that just slows everyone down is a tax, while friction that surfaces provenance is protection. The trick is keeping it the second kind.
That release-channel framing is the key. Once a commit path can ship to users, trust needs proof, not vibes. Provenance and review metadata are annoying until they prevent a compromised release from looking like ordinary maintenance.
"Trust needs proof, not vibes" is the line I'll be quoting back. That's the whole shift compressed: the moment a commit path can reach users, the author's word stops being enough, because the word is exactly what an attacker buys.
And your last point is the one that makes the friction worth it. Provenance and review metadata feel like pure overhead right up until the day they stop a compromised release from passing as ordinary maintenance, which is precisely how the April attack worked. A malicious update that looks like a routine patch is the thing the metadata exists to catch. Annoying until it isn't, and the day it isn't, it's the only thing standing there. Good exchange.
As someone who maintains open source tools, I had the same initial reaction; slower updates feel like a regression. But after thinking about it, the 24-hour hold is a reasonable tradeoff. The backdoor incidents this year proved that the old model of "commit and deploy instantly" assumed goodwill that doesn't hold at scale. I'd rather have a frustrated maintainer than 400,000 compromised sites. Plausible next step: signed commits required?
"Assumed goodwill that doesn't hold at scale" is the cleanest one-line version of what broke. The instant-deploy model wasn't naive, it just priced in trust that worked until commit access became something you could buy.
On signed commits: I think they're a likely next step, but worth being clear about what they fix and what they don't. Signing proves a commit came from the key it claims, which is real value against a hijacked account. The April incident is the harder case, because the attackers held the legitimate keys, they bought them. A signed commit from a purchased author is still a valid signature. So signing raises the floor, it doesn't replace the review layer, it strengthens the provenance half while the 24-hour check still has to cover the "legitimate author, malicious release" case. Both, not either. Identity you can verify, plus a release you can inspect.
This feels less like a delay and more like a maturity shift: trust is moving from “who committed this” to “did this change earn delivery.” That is a much healthier default for any software supply chain.
"Did this change earn delivery" is a better line than anything in the post. That's the whole shift in five words: trust moving from the identity of the committer to the merit of the change. Identity was always a proxy, and it held right up until identity itself could be bought. Judging the change instead of the person is the default that doesn't break when the person turns out not to be who you trusted.
That’s pretty concerning — it sounds like WordPress is now enforcing stricter commit validation or certificate checks, maybe related to HTTPS or signed commits. I’ve seen similar issues with Git hooks and CI pipelines when infrastructure keys are rotated or misconfigured. Have you checked if your SSH key or SVN client config needs an update? It’s a good move from a security standpoint, but the error message could be more helpful.
Appreciate the security take at the end, that's actually the whole point of the post. One clarification though: this wasn't an error on my end or a key/config issue to fix. Nothing broke. WordPress.org deliberately changed the default so that a committer's identity no longer implies the commit should be trusted, and the post is me arguing that's the right call, not a problem report.
So there's nothing to update on my side, and that's by design. The shift is from "trusted because we know who pushed it" to "verified because the change itself was reviewed," which holds even when the author's credentials are perfectly valid. A signed commit from a compromised or purchased account is still a valid signature, which is exactly why identity alone stopped being enough. I do agree the messaging around it could be clearer, that part you're right about.