On 5 June 2026, WordPress.org started making every plugin update wait. Under an initiative it named Protect the Shire, a new plugin or theme release no longer reaches sites the moment it is tagged. It sits in a holding window first, so that automated review, including a new Wapuu review bot the team calls Gandalf, can look at it before auto-updates push it to the world. The announcement set the window at 24 hours and said plainly that it “could be reduced to minutes as the process evolves.” By mid-July, community measurements of how long releases actually sat had it closer to six hours, after developers pushed back on the original day-long delay.
This is analysis, filed under our News desk. We think the instinct behind Protect the Shire is sound, and we also think the mechanism it shipped has a flaw it cannot fix by tuning the timer. The problem is not how long the hold is. The problem is that one hold is being asked to solve two threats that pull in opposite directions.
The threat the hold is built for
Auto-updates are a trust pipeline. You decide once that a plugin’s author is trustworthy, and from then on every release that author tags flows onto your site automatically, usually within hours, with no human in the loop. That convenience is the entire value of auto-updates, and it is also the exact mechanism an attacker wants.
We watched this play out earlier this year. An attacker bought a portfolio of plugins from their original developer, sat on them for months, and then shipped a backdoor disguised as a routine compatibility update. The auto-update pipeline did what it was built to do and delivered that release to every site running the plugins. We covered the timeline in our reporting on the Essential Plugin backdoor, and Patchstack, which triaged the incident, documented the compromise across more than 20 plugins.
Against that threat, a review window before distribution is a real defense. If a poisoned release has to sit for hours while an automated reviewer and a watching community look at it, some of those releases get caught before they ever land. Protect the Shire is a rational response to the worst WordPress supply-chain year on record. On its own terms, it is defensible.
The threat the hold ignores
Now the other half. Not every update is a Trojan horse. Most are the opposite: a developer fixing a vulnerability that has just been disclosed, racing to get the patch onto sites before attackers weaponize it.
That race is real and it is fast. A meaningful share of high-impact WordPress vulnerabilities are exploited within hours of public disclosure, because disclosure itself is the starting gun. The moment a fix is tagged, the changelog and the diff tell an attacker exactly what was wrong and how to hit anyone who has not patched. For that class of update, speed is not a convenience. Speed is the defense.
Here is where Protect the Shire gets blunt. As written, it does not distinguish between a plugin shipping a critical security fix and a plugin shipping a cosmetic tweak. The same hold applies to both. The window that catches a backdoor before it spreads also parks a security patch in a queue while the vulnerability it fixes is already being exploited in the wild. WordPress.org is holding the fix for the same reason, and for the same duration, as everything else.
One button, two opposite jobs
Strip the initiative away and you are left with the underlying fact it collided with. Auto-updates are, at the same time, your fastest defense and your largest supply-chain exposure. Speed protects you from the disclosed bug and endangers you from the poisoned release. Slowness does the reverse.
A single global setting cannot win both. Turn auto-updates on, and you are fast against disclosed vulnerabilities and wide open to a malicious release. Turn them off, and you invert the risk. Add a uniform hold in the middle, which is what Protect the Shire did, and you have not resolved the tension. You have just picked a fixed point on the slider and applied it to two problems that want the slider in different places.
The reason this is worth a thousand words rather than a hot take is that the WordPress ecosystem has been treating “update” as a single decision for its entire history. It never was. “Apply the code my plugin author just shipped” and “protect me from the bug that was just disclosed” are two different actions that happen to travel through the same pipe.
The case for decoupling them
If the two jobs are different, the obvious move is to stop making one control do both. That is the argument coming from the security-vendor side of this debate, and it is a coherent one whatever you think of the companies making it.
The mechanism is virtual patching: a mitigation rule that blocks a known exploit at the request layer the moment the threat is confirmed, without touching the plugin’s code and without waiting for the official fix to clear any queue. The vendor rule handles the disclosed-vulnerability race, closing the gap between disclosure and patch deployment, while the actual code update can still sit behind a review hold to catch supply-chain tampering. One control optimized for speed, a different control optimized for scrutiny.
Patchstack has taken this position publicly and pointedly, pressing WordPress.org to fast-track security fixes specifically rather than holding them like any other release, and backing the argument with its own measurements of how long tagged releases sit before the update API serves them. That is a vendor with a product in the mitigation market making the case, which is worth keeping in mind. It is also, on the merits, the same conclusion the tradeoff points to on its own: a hold that cannot tell a fix from a feature is taxing the fix.
What this means for your sites
The uncomfortable part of this story is that the decoupling Protect the Shire does not do is decoupling you can, and probably should, do yourself. The tradeoff is not WordPress.org’s to resolve on your behalf. It is a set of per-plugin decisions.
Start by splitting your plugins by blast radius rather than by convenience. The plugins that would do the most damage if a release were poisoned, anything handling commerce, authentication, form submissions, or user data, and especially any plugin that has recently changed hands, are the ones where a malicious update hurts most. Those are the plugins to take off blanket auto-update and stage: let a release age, watch the changelog and the community, then apply. For low-risk plugins where the real danger is a disclosed bug going unpatched, fast updates still make sense.
Then stop depending on update timing alone for known exploits. A firewall or virtual-patching layer means a confirmed exploit is blocked whether or not the fix has landed yet, which is the whole point of separating mitigation from patching. We walk through where this fits in the wider stack in our WordPress security checklist, and the single highest-signal thing to monitor is ownership: a plugin quietly changing developers is the tell that preceded most of this year’s supply-chain incidents.
The interesting part
Protect the Shire is a reasonable reaction to a genuinely bad year, and the people behind it are not wrong that unreviewed releases are a threat. It is also a blunt instrument that slows down the one kind of update you most need to arrive fast, and no amount of shortening the timer changes that, because the flaw is in treating one hold as the answer to two questions.
We keep coming back to the same shape on this desk. A performance feature that quietly switched off a firewall. A convenience default that becomes an attack path. And now an update pipeline that is a defense and a liability in the same motion. The lesson is not that WordPress.org made the wrong call. It is that “update” was never one decision, and the ecosystem is only now being forced to admit it.
