Introduction
WordPress.org now holds every new plugin release for up to six hours before it reaches auto-updates. Patchstack measures the median time from public disclosure of a vulnerability to mass exploitation at five hours. Both numbers have been sitting in the public record since July and nobody has put them next to each other.
In short
- Six hours is the current hold on a plugin or theme release under the Protect the Shire initiative. It started on 5 June 2026 at up to 24 hours and was cut to six before 18 July 2026.
- Five hours is the median time to mass exploitation of a high-impact vulnerability, per Patchstack’s State of WordPress Security in 2026, published 25 February 2026.
- 46 percent of vulnerabilities have no patch at the moment of public disclosure. That figure is from the same report and it changes what the first two mean.
- The public record does not say whether a security patch is exempt from the hold. The announcement refers to every new release and draws no distinction.
- The cut to six hours was announced on Slack only. Plugin authors discovered it when shipping.
- 11,334 new vulnerabilities in the ecosystem in 2025, 42 percent more year on year, with easily exploitable ones up 113 percent.
- 12 percent of known WordPress attacks are stopped by common host and WAF setups. That figure trims the advice I go on to give.
Where the hold came from
In April 2026 thirty-one plugins from a single brand were pulled from the directory at once. Every one of them carried a backdoor. Nothing was broken into: somebody bought the plugins on Flippa, inherited SVN commit access with them, and pushed one malicious update dressed up as a WordPress 6.8.2 compatibility patch.
It is worth breaking that attack into steps, because each one is legal on its own and only together do they add up to a compromise. Buying a plugin on a marketplace is legal. Inheriting the repository account with it is within the rules, because that is what a change of ownership looks like. Pushing an update is an author’s normal act. Labelling it a compatibility patch for a specific WordPress release is plausible, because such patches were genuinely going out at the time. The blast radius was reported at up to 400,000 sites.
No link in that chain looks suspicious by itself, and that is the point. A control based on who pushes the code had nothing to detect, because the code was pushed by the rightful owner. The only thing that could be detected was what was inside.
That is a supply-chain attack in its purest form, and the directory had no answer to it, because the whole trust model rested on the assumption that whoever holds commit access is who they say they are. Protect the Shire answers exactly that scenario. It inserts a window between commit and distribution, in which an automated reviewer and a human can look at what is about to ship to millions of installs.
As an answer to that attack the hold makes sense, and I want to say so plainly before I get to the objection. Six hours between a malicious commit and auto-update is six hours that did not exist before.
Where the six hours stop helping
The hold is neutral about what a release contains. It does not know whether the payload is a new feature, a typo fix, or a patch for a vulnerability under active exploitation. The 5 June announcement refers to every new release and makes no distinction. I also found no source describing an expedited path for security releases.
I want to be precise here, because this is where it is easy to write something untrue. I am not claiming that no expedited path exists. I am making a weaker, checkable claim: it is not documented where a plugin author would find it, which is the announcement and the public posts that followed. For an author who has just received a vulnerability report and is preparing an emergency release, an undocumented path is functionally the same as no path.
That is where the second number lands. Patchstack puts the median time to mass exploitation of a high-impact vulnerability at five hours from public disclosure. Median, not mean, so half the cases move faster.
Putting the two numbers side by side needs care, because they measure different things. Six hours is a delay on distributing an update. Five hours is the time from disclosure to attack at scale. They do not line up perfectly, and I am not claiming every patch arrives an hour late. I am claiming that the directory’s protective window is the same order of magnitude as the attack window, and at that ratio, buffering a release stops being free.
The number that changes the other two
The same Patchstack report states that 46 percent of vulnerabilities had no patch at the moment of public disclosure.
That figure resets the whole discussion. In almost half of cases there is nothing to hold, because there is no release yet. The hold costs nothing there, but it also gives nothing, and the only thing protecting a site is a layer that does not wait for the directory: a WAF rule, a disabled feature, a deactivated plugin.
In practice this means the argument about six hours applies to a little over half the cases. For the rest the question is a different one, and the directory is not a party to it.
The scale that makes six hours matter
Six hours sounds harmless until you set it against the number of events passing through that window.
Patchstack counted 11,334 new vulnerabilities in the WordPress ecosystem in 2025, 42 percent more than the year before. That is more than thirty a day on average. Rising volume alone would be bearable if it rose evenly, but it does not: vulnerabilities classed as easily exploitable rose 113 percent year on year, more than doubling.
Together those two figures change the character of the problem. It is not that there are more holes. It is that the fastest-growing share is the part that can be exploited without effort, which means at scale and by machine. With that profile, a five-hour median to mass exploitation stops being a statistical curiosity and becomes a description of a normal day.
In that light a hold at the directory is one of the few levers that works at scale at all. An automated reviewer looking at every release scales better than any process that depends on a plugin author or a site administrator reacting in time. That is why I think the direction is right, and the argument is only about whether the window should stay blind to what a release contains.
A correction to my own advice
I wrote above that you should build a layer that does not wait for the directory, and pointed at a WAF rule. The same Patchstack report contains a figure that trims that advice hard, and I am not going to bury it.
In penetration testing, common host and WAF setups blocked 12 percent of known, actively exploited WordPress-specific attacks, and 26 percent of a broader test set. Eight in ten real attacks go straight through what most agencies count as their protective layer.
The distinction that rescues the advice is concrete and worth naming. A generic host WAF filters generic patterns, the crude SQL injection attempts and path scans. A vulnerability in a specific plugin usually does not look like a generic attack. It looks like a valid request to a valid endpoint with one parameter set in a way the author did not anticipate. A generic rule cannot see that.
A rule written against a specific disclosed CVE is a different thing, what the industry calls virtual patching. It does not need to understand a class of attack, it only needs the signature of this one. That is the layer I meant, and I want to be precise about it: the point is not to own a WAF, it is to have a process for adding a rule within hours of disclosure. Merely having a WAF is worth less than is commonly assumed.
There is an honest caveat about the source. Patchstack sells virtual patching, so a figure showing generic WAFs to be weak suits them. That does not make it false, and the methodology is described in the report as penetration testing against a known exploit set. It does mean the figure should be read knowing who published it. I mention it so nobody has to discover it for themselves.
The plugin author’s side, which is half the problem
So far I have written from the position of someone maintaining other people’s sites. A plugin author has the same problem inverted, and their version is harder, because they are the one sitting against the clock.
The scenario runs like this. You receive a vulnerability report, usually through a bug bounty programme or directly from a researcher. You agree a disclosure date, prepare the patch, test it, ship the release. Until June 2026 the gap between commit and distribution was minutes. It is now up to six hours, and there is no publicly documented way to shorten it.
The practical consequence is that the disclosure date agreed with the researcher needs slack in it. If you agree on Monday at nine, the release has to go out on Sunday evening, not Monday at eight. Against a five-hour median to mass exploitation, that hour is real.
The second consequence is about on-call. Developer Lopo put it most briefly: discovering only after release that shifts had to be rearranged to watch the rollout. If you ship a plugin with half a million installs, somebody has to watch the reports during the hours the update actually propagates. With a window that moves and is not announced publicly, that cannot be planned.
The third is subtler. The hold changes what a version number means. Until now, pushing 2.4.1 meant 2.4.1 was in circulation. Now it means it will be, and in the meantime what is in circulation is 2.4.0, the vulnerable version that is already publicly known to be vulnerable. Release notes have to account for that, or “fixed in 2.4.1” is true and misleading at the same time.
Gandalf, or trust moved rather than removed
The hold checks nothing by itself. What matters is what happens during it, and in the announcement that role falls to an automated reviewer called Gandalf.
It is worth noticing what actually changed in the trust model. Until April the directory trusted whoever held SVN access. After April it is known that such access is sometimes bought along with the plugin, so trust was taken away from that place. It was not abolished, it was moved onto an automated reviewer that judges the content of a release.
That is the better arrangement, and I will say so plainly, because an automated reviewer cannot be bought on Flippa. But it introduces two new questions the public record does not answer.
The first is about errors in the other direction. A scanner that lets a malicious release through is the obvious problem. A scanner that blocks a legitimate release is the quieter one and, for an author, the more painful, because it is unclear who to appeal to or how long it will take. I found no description of an appeals procedure.
The second is how long the scan itself takes. If it takes twenty minutes, then the six-hour window is ninety-five percent buffer rather than work, and the proposal to skip the hold on a clean result solves essentially the whole problem. If it takes five hours, the opposite is true. That single number changes the conclusion and it is not published.
Slack is not an announcement channel
The cut from 24 hours to six shipped without a public post. Ajay D’Souza found it while releasing a plugin before 18 July 2026. Enrico Battocchi asked directly how they were supposed to learn about such changes and whether there would be a post. A developer going by Lopo described the operational cost: discovering only after release that shifts had to be rearranged to watch the rollout.
This is a separate problem from the hold itself and, to me, the more serious one. A plugin author plans an emergency release around a known delay. If the delay changes without notice, planning breaks in both directions. Sometimes you wait longer than you budgeted for, sometimes it ships sooner and nobody is watching the rollout.
A draft proposal exists to skip the hold when the Gandalf scan returns no findings. The version it scanned stops waiting and starts being served. That would solve most of the problem, because a clean scan is the overwhelming majority of releases. The proposal is under review and has not been implemented.
What to do on the site side
If you maintain client sites, the directory hold is a variable you do not control. Four others you do.
Do not turn off auto-updates in response to this change. It is the common reflex and it is the opposite of what the numbers support. The hold costs hours. Clicking manually costs days, and across six locales and dozens of sites it costs weeks. Since half of critical flaws are exploited in the first 24 hours, your own reaction time is the larger risk.
It helps to look at the arithmetic. The hold adds at most six hours. Updating by hand once a week gives an average delay of around eighty-four hours, fourteen times more. Even updating by hand every day averages twelve hours, still double the directory window. So anyone arguing that the hold is too risky and switching to manual is trading six hours for several dozen.
Build the process for adding a rule, not just the WAF. After the correction above this reads differently from the usual advice. Owning a host WAF stops twelve percent of known WordPress attacks, per Patchstack’s testing. The value is in being able to add a rule for a specific, freshly disclosed CVE within hours. That is the difference between a product and a procedure, and here the procedure is what decides.
Keep a list of the plugins that are business-critical for each client, and know which one can be switched off for an hour. Deactivating a form plugin until the patch lands is cheap. Deactivating a payment gateway is not. That distinction belongs in a document written before the incident, not during it. In practice it is one column in a spreadsheet, filled in once when the site is taken on.
Know where you will hear about a vulnerability before you hear about it from monitoring. The information channel matters as much as the technical layer here, because against a five-hour median the difference between learning in the morning and in the evening is the difference between a patch and an incident. A vulnerability feed read daily is cheaper than any tool, and it sets the ceiling on how fast you can react at all.
What this change does not fix
It is worth saying plainly what the hold does not touch, because it is easy to overrate.
It does not touch plugins from outside the directory. A premium plugin bought directly from its author or on a marketplace updates through its own channel, and no cooldown covers it. A typical WooCommerce store runs several of those, often the most sensitive ones, because they handle payments, shipping and customer data.
It does not touch themes and plugins installed by hand from a ZIP, nor the code in a client’s own functionality plugin. And that is exactly where the debt usually sits, in code written ad hoc and left untouched for years.
Finally it does not touch the case where the code is not the problem at all and the configuration is: permissions too broad, an administrator account without a second factor, an API key committed to a repository. The directory has no role there, and such cases make up a high share of real incidents.
What I do not know
Three things stay open, because I have no source for them and I am not going to guess.
I do not know whether security releases have an expedited path that has not been documented publicly. I do not know how long a full Gandalf scan actually takes, so I do not know how much of the six hours is work and how much is buffer. I do not know when, or whether, the proposal to skip the hold on a clean scan will be implemented.
If any of these is documented publicly, I will update this post and date the change.
Sources
- Protect The Shire, WordPress News, 5 June 2026
- Patchstack, State of WordPress Security in 2026, 25 February 2026
- The cooldown cut to six hours and the developer reaction
Last verified: 10 August 2026.
