Since June 2026, WordPress.org holds every plugin and theme release behind a mandatory cooldown before it reaches your dashboard. The delay started at 24 hours and has sat at roughly six hours since 16 July 2026. Security patches get no exemption. This means your WordPress site can report “everything is up to date” while a patched version of a plugin you run is already public, with the vulnerability described in its changelog.
By Cody Wise, Founder, Wise Media. Published 24 September 2026.
Summary
- The initiative is called Protect the Shire. Announced by Matt Mullenweg on 5 June 2026, it applies to all 78,000 plus plugins and themes in the WordPress.org directory.
- It gates the update check API, not just auto updates. One click dashboard updates are delayed identically, which contradicts the original announcement and was never corrected.
- Security fixes clear at the same median speed as cosmetic ones. There is no fast lane, though authors can email the Plugins Team for an expedited release.
- It has already worked at least once. A backdoor in Advanced Responsive Video Embedder was caught inside the cooldown in July 2026 and never reached users.
- As of 9 September 2026 the cooldown also runs an automated security review that can block a high risk release automatically, with no human in the loop.
- What you should do: almost nothing, except understand that your “up to date” screen is now a lagging indicator, and keep auto updates on.
Table of contents
- What Protect the Shire actually is
- The problem it was built to solve
- The detail the announcement got wrong
- The tradeoff, argued honestly from both sides
- What it costs the people writing your plugins
- September 2026: automated blocking arrives
- What a site owner should actually do
- FAQ
What Protect the Shire actually is
Protect the Shire is the official name, not a nickname. Matt Mullenweg announced it on the WordPress.org news blog on 5 June 2026, timed to WordCamp Europe. His own summary described a “temporary 24-hour cooldown period for plugin/theme releases before auto-updates.” The automated reviewer picked up the nickname Gandalf.
The mechanics are straightforward. When a plugin author tags a new release, the zip file publishes to WordPress.org immediately, but the update API does not advertise the new version to your site until the cooldown expires. During that window the release is analysed for signs of malicious code.
| Date | Change |
|---|---|
| 5 June 2026 | Protect the Shire announced. Cooldown up to 24 hours |
| 7 to 15 July 2026 | Measured median gate of 24.2 to 24.5 hours |
| 16 July 2026 | Reduced to roughly 6 hours, announced only in the Slack meta channel |
| 28 July 2026 | A backdoored release is intercepted inside the cooldown |
| 9 September 2026 | Automated security review with automatic blocking goes live |
The reduction to six hours is worth noting for how it happened. It was communicated in a Slack channel, not a public post, and was confirmed externally only because the security firm Patchstack was measuring release times independently rather than taking WordPress.org at its word. Their data shows a single day step change on 16 July with no ramp.
The problem it was built to solve
Not the CVE wave. Something narrower and harder to defend against: plugins that get acquired, inherit commit access, and go bad later.
The case Mullenweg cited is the Essential Plugins situation. A set of 31 plugins was purchased through Flippa and backdoored roughly eight months after the sale, hitting an estimated 20,000 sites in April 2026. It was one of four plugin backdoors disclosed in a four week stretch.
That attack pattern defeats almost every defence a site owner has. The plugin was legitimate when you installed it. It had good reviews, an established install base and a real changelog. The author account was not compromised, because the attacker was the author by then. Reputation based judgement fails completely against a purchased plugin.
Volume is the second driver. Weekly plugin submissions to WordPress.org went from roughly 150 per week in 2024 to more than 500 per week in early 2026, largely AI assisted, with over 3,000 commits to the repository in a single day. Human review does not scale to that. A mandatory window that machines can inspect does.
It has already caught something real
On 28 July 2026, a backdoor in Advanced Responsive Video Embedder, a plugin with roughly 20,000 installs, was caught during the cooldown. The vulnerability was later catalogued as CVE-2026-18072 at CVSS 9.8. Wordfence found it in about two hours, and WordPress.org’s own automated review flagged it independently. The compromised version never reached a single site.
That is the strongest argument for the policy, and it is worth stating plainly before the criticism, because the criticism is also good.
The detail the announcement got wrong
Mullenweg’s post said the cooldown applied to auto updates. It does not. It applies to all WordPress.org served updates, including the one click update button in your dashboard.
The reason is architectural. The gate sits on the update check API, and both automatic and manual updates read from the same endpoint. Samuel “Otto” Wood confirmed this in the plugin review channel. Elementor’s release manager Rebecca Markowitz flagged it within hours of launch. The original announcement was never corrected.
This matters operationally, because it removes the obvious workaround. If you read about a critical vulnerability in a plugin you run, log into your site and click Update, you may get nothing, with no explanation of why.
The two escape hatches that do work
- Manual install. The zip publishes to WordPress.org immediately. Download it, then upload it through Plugins, Add New, Upload Plugin, or delete and reinstall. This bypasses the cooldown entirely and works today.
- Author expedite. WordPress.org shows plugin authors a notice on the pending version page: “If this update fixes a security issue that needs to ship sooner, contact plugins@wordpress.org.” Plugins Team co-rep Francisco Torres has said these requests run at a few per day.
Torres rejected a proposal to automatically exempt any release its author self declares as a security fix, and his reasoning is hard to argue with: the Advanced Responsive Video Embedder attacker disguised the backdoor as a security update. An automatic exemption for self declared security fixes would be an automatic exemption for exactly the attack the system exists to stop.
The tradeoff, argued honestly from both sides
Most coverage of this picked a side. The honest position is that both sides are right about different risks.
| The case for the cooldown | The case against it |
|---|---|
| Catches supply chain attacks that reputation cannot detect | Changelogs publish instantly while patches do not, which hands attackers a map |
| Already intercepted a CVSS 9.8 backdoor before distribution | Patchstack puts weighted median time to first exploitation for heavily targeted vulnerabilities at about five hours, shorter than the six hour hold |
| Scales to 500 plus submissions per week where human review cannot | Applies equally to a security patch and a typo fix |
| Expedite path exists for genuine emergencies | The expedite path depends on volunteers being awake and not travelling |
Elementor’s Miriam Schwab, who oversees 14 plugins with more than 10 million combined installs, made the sharpest version of the objection: malicious actors can read the published changelog, analyse what the fix changes, and exploit the gap during the delay. GeneratePress author Tom Usborne initially supported the policy and reversed once the manual update scope became clear, calling a state where the zip ships but the update button does nothing something that “just creates confusion and feels broken.”
Patchstack’s July analysis found that of 114 tracked releases, 81 patched a disclosed CVE across 79 plugins with roughly 9.9 million combined installs. Thirty were rated CVSS 7.0 or higher, nine at 9.0 or higher, one at 10.0.
And the fact that settles the temperature of this debate: Patchstack found no actual exploitation during any window it measured. The theoretical risk is real and the measured harm so far is zero. Anyone telling you your sites are being actively exploited because of this is selling something.
What it costs the people writing your plugins
There is a human cost story here that explains the developer anger better than any of the technical arguments, and site owners should understand it because plugin maintainer burnout is a direct risk to their sites.
In August 2026, Pods, a long established content framework plugin, had to patch an unauthenticated privilege escalation rated CVSS 9.8. Scott Kingsley Clark, the unpaid sole maintainer, took a week off his day job to backport the fix across six major versions, from the 2.7 line through 3.3. He emailed the Plugins Team roughly an hour before pushing on 14 August.
That weekend was WordCamp US. Plugins Team members were travelling, and some of the backported releases sat in the cooldown waiting on people who were on planes. A second round of patches followed on 31 August. Clark’s own comment was that “all it would take to burn me out bad was a few of these.”
The lesson for a business owner is not about policy. It is about dependency. Every plugin on your site is a supply chain relationship with someone, and a meaningful number of those someones are volunteers. When you are choosing plugins, funding matters as much as features.
The plugin selection questions that follow from this
- Is there a commercial entity or funded team behind it, or one unpaid maintainer?
- How fast did they ship the last disclosed CVE fix?
- Has the plugin changed hands? Check the changelog and support forum for an ownership transition.
- How many active installs, and is the author responsive in the support forum in the last 90 days?
- Do you actually need it, or is it doing something your theme or a few lines of code could do?
That last one is the highest leverage security control available to most sites. Every plugin you remove is a dependency you no longer have to trust, patch or monitor. Our runbook on the August 2026 CVE wave covers the triage side of this in detail.
September 2026: automated blocking arrives
On 9 September 2026 the Plugins Team turned the cooldown into something more than a waiting room. Every release is now analysed during the window by several AI models plus Jetpack Scan, cross checked into a risk score, and releases at or above a blocking threshold are withheld from the update API automatically, with no human review required.
This is now documented in the official Plugin Handbook. David Perez of the Plugins Team framed the design constraint precisely: “The score measures risk, not intent.” A blocked release is not a closed plugin, and the remedy is to ship a new version rather than to appeal.
Two implications for site owners.
First, the cooldown now buys something concrete rather than just time. In June the argument for it was that a delay creates space for someone to notice a problem. As of September, something is actively looking during that space.
Second, the six hour figure is likely to shrink. Perez has said publicly the cooldown will be reduced if the automated system runs clean, and there is an open pull request to skip the cooldown entirely for releases that return zero findings, which would cut the wait to minutes for most updates. That had not merged at the time of writing. If you are reading this months from now, check the current state before assuming six hours still applies.
The other 2026 changes worth knowing about
| Measure | Status | Affects you? |
|---|---|---|
| Mandatory two factor authentication for plugin and theme committers, plus separate high entropy SVN passwords | In force since 1 October 2024 | Indirectly. It hardens the accounts that ship your code |
| Release Confirmations, an opt in email confirmation step before a tagged release goes out | Available, still opt in, underused | Only if you publish plugins |
| Automatic Plugin Check on every update | Rolling since October 2025 | No action needed |
| Phased plugin releases with an optional 24 hour delay | Landed August 2025, opt in. Protect the Shire is the mandatory version | No action needed |
| Formalised Core Security Initiative | Announced 1 September 2026 | No action needed |
For context on core itself, WordPress 7.1.1 shipped 18 September 2026 with 11 fixes, and 7.1.2 followed on 23 September with a critical remote code execution fix. Core security releases are not subject to the plugin cooldown. Apply those immediately.
What a site owner should actually do
Here is the honest answer, which is less dramatic than the headlines: for most business websites, almost nothing changes. The practical delta for a five page brochure site is close to zero.
What genuinely changes is one thing, and it is worth internalising.
Your “Plugins are up to date” screen is now a lagging indicator
For up to six hours, a patched version can be live on WordPress.org, with the vulnerability described publicly in its changelog, while your dashboard shows nothing to do. That green state is not proof you are patched. It is proof that the API has not told you yet.
Your maintenance tooling does not save you from this. Management dashboards, host updaters and agency tooling mostly read the same update API. WP Engine’s updater ended up matching the delay. If you run 30 client sites, this is not a six hour gap on one site, it is a six hour blind spot across the entire fleet simultaneously.
The checklist
- Leave auto updates on. Nothing in this story argues for turning them off. The delay applies either way, and auto update still patches you faster than a human who checks on Tuesdays. Anyone using this news to justify disabling auto updates has drawn the wrong conclusion.
- Subscribe to a vulnerability feed, not your dashboard. Patchstack or Wordfence will tell you about a disclosed CVE before your update screen does. That is now a structural advantage, not a nice to have.
- Know the manual install path before you need it. Download the zip from the plugin’s WordPress.org page, then Plugins, Add New, Upload Plugin, and overwrite. Practise it once on a staging site so you are not learning it during an incident.
- Reserve that path for real emergencies. Unauthenticated remote code execution or privilege escalation in a plugin you actually run, actively exploited. Not every CVE warrants bypassing a safety mechanism built to protect you.
- Cut plugin count. The most effective response to a supply chain risk is a smaller supply chain.
- Apply core security releases immediately. They do not go through the plugin cooldown.
- If you manage client sites, write the six hour gap into your incident policy so the decision to bypass is made calmly in advance rather than at 11pm.
Who should actually change behaviour: anyone running WooCommerce, membership, booking or form plugins, and anyone maintaining sites on behalf of clients. Everyone else can read this, understand it, and carry on.
Common mistakes
- Disabling auto updates in response. This makes you strictly worse off. The cooldown applies to manual updates too.
- Treating the update screen as an audit. It is a notification, and a delayed one.
- Bypassing the cooldown routinely. Manually installing every release defeats the protection and reintroduces exactly the risk the system was built to catch.
- Assuming your host or maintenance provider is ahead of it. Ask them directly. Most read the same API.
- Panic buying a security plugin. A vulnerability feed subscription and fewer plugins beats another plugin.
- Assuming the six hour figure is permanent. It was 24 hours in June. A pending change may cut it to minutes.
Frequently asked questions
What is WordPress Protect the Shire?
Protect the Shire is a WordPress.org security initiative announced by Matt Mullenweg on 5 June 2026 that holds every plugin and theme release for a mandatory cooldown period before the update API advertises it to sites. It applies to all 78,000 plus plugins and themes in the directory and exists to catch supply chain attacks, particularly backdoors introduced into plugins that have changed ownership.
How long is the WordPress plugin update delay?
Roughly six hours. It launched at up to 24 hours on 5 June 2026 and was reduced to about six hours on 16 July 2026. The Plugins Team has said the window will shrink further if the automated security review introduced on 9 September 2026 performs well, so verify the current figure before relying on it.
Does the delay apply to security patches?
Yes. There is no automatic fast lane for security fixes, and measured data shows security releases clear at the same median speed as cosmetic ones. Authors can request an expedited release by emailing plugins@wordpress.org, and those requests run at a few per day. A proposal to auto exempt self declared security fixes was rejected because a known attacker disguised a backdoor as a security update.
Does the cooldown affect manual updates or only auto updates?
Both. The original announcement referred only to auto updates, but the gate sits on the update check API, which serves the one click dashboard update button as well. Downloading the zip from WordPress.org and uploading it manually bypasses the cooldown entirely, because the file itself publishes immediately.
Should I turn off WordPress auto updates because of this?
No. The delay applies to manual updates too, so disabling auto updates removes a protection without removing the delay. Auto updates still patch your site faster than a human checking periodically. Keep them on and subscribe to a vulnerability feed for early warning.
Has anyone actually been hacked because of the update delay?
No confirmed exploitation has been observed during any measured cooldown window. Patchstack, which has been critical of the policy, found none in its own tracking. The risk is theoretical so far, while the policy has at least one documented save: a CVSS 9.8 backdoor in Advanced Responsive Video Embedder was intercepted during the cooldown in July 2026 and never reached users.
How do I update a plugin immediately without waiting?
Download the current zip from the plugin’s WordPress.org page, then go to Plugins, Add New, Upload Plugin and install it over the existing copy, or deactivate, delete and reinstall. Take a backup first. Reserve this for genuine emergencies, because routinely bypassing the cooldown reintroduces the risk it was designed to prevent.
The bottom line
WordPress made a deliberate trade: a few hours of delay for every site in exchange for a window in which supply chain attacks can be caught before distribution. Reasonable people disagree about whether that trade is correct, and the disagreement is genuine rather than manufactured.
For a business owner the practical takeaway is narrow and worth remembering: the green “up to date” badge on your plugins screen is a notification with a lag, not a statement of fact. Build your patching process around a vulnerability feed instead, keep your plugin count low, keep auto updates on, and know how to install a zip manually before the night you need to.
Need someone watching this for you?
Most businesses do not want to track WordPress.org policy changes, CVE feeds and plugin ownership transfers. That is reasonable, and it is exactly what a maintenance retainer is for. Wise Media maintains Canadian business sites with vulnerability monitoring, staged updates and a documented emergency patch path. If you want that handled, start with our project intake form.
Related reading: what a WordPress maintenance plan should include, our Elementor Pro vulnerability runbook, and the August 2026 plugin CVE wave runbook. Planning a platform move? See our WordPress migration guide or our website growth packages.