Protect The Shire: WordPress Adds a 24-Hour Default Delay to Plugin Auto-Updates

On June 5, 2026, Matt Mullenweg published “Protect The Shire” on the WordPress.org news blog, announcing that every new plugin release in the official directory will wait up to 24 hours before being distributed through auto-updates. The change applies by default to the 61,000+ plugins hosted in the directory; the post’s tl;dr summary also references theme releases under the same framing. The delay infrastructure has been live since August 11, 2025 as an opt-in feature plugin authors could enable on individual releases. The June 5 announcement keeps the same delivery mechanism and flips the default. The delay now applies to every release.

For managed WordPress hosts that run auto-update pipelines across customer fleets, the practical effect is a one-day buffer between when a plugin author presses “release” and when that code reaches sites. Mullenweg framed the move as a response to AI-accelerated supply chain risk, pointing to April’s Essential Plugins backdoor and Anthropic’s Mythos reveal as catalysts. The cost: Patchstack’s 2026 security report finds that approximately half of high-impact WordPress vulnerabilities are exploited within 24 hours, so the safety buffer also delays legitimate security patches.

Mullenweg posted “Protect The Shire” the same day he announced he would not attend WordCamp Europe 2026 in person; the text doubled as his prepared closing keynote.

Key facts

• Announced: June 5, 2026 by Matt Mullenweg on WordPress.org
• Mechanism: 24-hour delay before every new plugin release reaches auto-updates (post’s tl;dr also references theme releases)
• Coverage: WordPress.org plugin directory by default
• Prior status: opt-in via Release Confirmations since August 11, 2025
• AI review: a new Wapuu named Gandalf, framed as an AI-driven plugin reviewer
• Manual updates: site admins can still install immediately from the dashboard
• Stated drivers: Mythos AI threat, Essential Plugins backdoor, broader supply chain attacks

The Infrastructure Was Already There. The Default Just Flipped.

The phased plugin releases feature has been in production for ten months. Mullenweg first proposed it in June 2025. It went live on August 11, 2025 inside Release Confirmations, the existing controlled-release feature for plugin authors. A plugin author who wanted to delay auto-updates chose the option at publish time. Sites running WordPress 6.6 or later received the instruction to wait; older sites could not be told to hold back.

The June 5 announcement removes the opt-in. Every new plugin release will now wait up to 24 hours before WordPress.org instructs sites to apply the auto-update. Mullenweg signalled that the 24-hour window could compress to minutes “as the process evolves,” but the project will stay cautious while AI capabilities are advancing. Manual updates from the site dashboard remain immediate.

The distinction matters for plugin authors who relied on instant distribution. A security patch pushed to the directory will not reach the average WordPress site through auto-updates until the next day. Site administrators watching the directory or running independent vulnerability monitoring (Patchstack, Wordfence) can still apply updates within minutes. The default delay affects sites that rely on WordPress.org’s distribution cadence to schedule their own update window, which is the majority of the installed base.

The AI Acceleration That Triggered the Flip

The “Protect The Shire” post is explicit about its rationale. Three events in the preceding seven months changed Mullenweg’s reading of the risk: the December 2025 “step-change in coding ability” that Andrej Karpathy described publicly, the April 7, 2026 reveal of Anthropic’s Claude Mythos Preview, and a string of supply chain incidents that translated AI capability into attacker advantage.

Mythos is the central reference. Anthropic withheld it from public release because internal testing showed it could develop working exploits in 72.4 percent of attempts, against a near-zero baseline for prior Claude models. It identified thousands of previously unknown vulnerabilities across every major operating system and every major web browser, including a 27-year-old denial-of-service flaw in OpenBSD and a 17-year-old remote code execution flaw in FreeBSD. The model was distributed to approximately 40 organizations through Project Glasswing, an invitation-only consortium that includes Amazon Web Services, Microsoft, Google, Cisco, and the Linux Foundation. Defenders inside Glasswing have the model. The public does not. Mullenweg’s working assumption in the post is that the access gap will narrow over time, and that AI agents capable of reading source code at scale will be available to attackers as well as defenders.

The supply chain incidents made the abstract risk concrete. The Essential Plugins backdoor, dormant for eight months in 31 plugins from a single account, activated on April 6, 2026 against more than 20,000 sites. The same week, Smart Slider 3 Pro’s update infrastructure was compromised and a backdoored version 3.5.1.35 reached the update channel for roughly six hours before detection. Mullenweg referenced the Essential Plugins incident in the post and noted broader supply chain attacks across npm, PyPI, GitHub, and RubyGems. The pattern is consistent: a release with malicious code can reach millions of sites in the time it takes a reviewer to notice.

A Plugin Review Team That Can’t Sleep

WordPress.org’s human plugin review team handles a workload that scales with the directory, not with the team’s hours. The June 1, 2026 Plugin Team update reports 605 plugin submissions for the prior period, 558 approved, 201 rejected, and a queue of 4,740 items, of which 4,170 have been waiting more than seven days. The support inbox logs 1,940 conversations and a 242-message daily average. Mullenweg describes the team as “superhuman” in the post, but the math is plain: an existing plugin’s commit triggers no automated security review, and Mullenweg notes over 3,000 commits to the plugin repository in a single day.

The 24-hour cooldown is the buffer that makes systematic AI-assisted review possible without slowing developer velocity to a crawl. The review work has a name in the post: Gandalf, a new Wapuu (the WordPress mascot character family). The post does not identify a specific AI model or vendor. It describes the role: bot-driven security analysis of every plugin release before it reaches auto-updates. The 24-hour window is the time the automated review needs to run. The window shrinks as the tooling matures.

Mullenweg’s reasoning is symmetric: AI accelerates the attacker, so the defense has to use AI to keep up. The team’s workload numbers explain why human review alone cannot absorb the increase in attack tempo. Buffering every release for an automated pass is the path WordPress.org has chosen; the alternatives would require either expanding the review team or restricting who can publish.

Where the Delay Lands for Managed WordPress Hosts

For hosting providers running auto-update pipelines, the default 24-hour delay shifts what was previously a host-specific operational policy to a platform-level standard. Several managed hosts already introduce delays through internal review or staging processes (WP Engine reviews releases before pushing; Pressable and Kinsta offer integrated staging). For those hosts, the WordPress.org delay is consistent with existing practice and the new default is invisible to customers. For hosts that pass auto-updates through with minimal staging, the new default closes a multi-tenant exposure that the Essential Plugins incident demonstrated: hosts that pushed automatic updates between August 2025 and April 2026 distributed the backdoor across their entire WordPress fleet without an opportunity for the directory to flag it.

The delay is the difference between distributing a compromised release to thousands of customers in minutes and distributing it after a day, by which time the directory has had time to flag the release and pull it. It is not a substitute for host-side review, malware scanning, or staging environments. It is a baseline that hosting customers now receive by default, without any host-side action.

The trade runs the other way for legitimate patches. A security fix pushed by a responsible plugin author now waits 24 hours before reaching the hosted site through auto-updates. Hosts that run their own vulnerability monitoring can detect the patch, validate it, and push it manually within minutes. Hosts that rely on WordPress.org’s distribution cadence will see patches arrive a day later than before. For shared hosting where the host does not maintain an update workflow beyond what WordPress.org distributes, the customer sees the delay directly. Major managed WordPress hosts had not made public statements on Protect The Shire as of this writing.

The Speed-versus-Safety Tradeoff Mullenweg Acknowledged

The 24-hour window collides directly with the speed of WordPress plugin exploitation. Patchstack’s 2026 State of WordPress Security report finds that approximately half of high-impact WordPress vulnerabilities are exploited within 24 hours, with a weighted median time-to-first-exploit of five hours. The default cooldown means that for half of high-impact disclosures, the patch reaches auto-updates at roughly the same time the exploit reaches scanners. The buffer that protects against a malicious release is the same buffer that delays a defensive one.

Mullenweg acknowledged this directly. The post frames 2026 as “a year of tension between two approaches: updating as quickly as possible to stay secure, and holding back on updating to stay secure.” The directory is choosing the second approach as the default and is betting that automated review will compress the cooldown over time. The compression depends on how quickly AI-assisted security review matures and how reliably it catches the kinds of subtle compromise the Essential Plugins backdoor used. Neither factor has a clear timeline.

For the hosting industry, the practical question is which actor manages the safety-versus-speed trade. Before June 5, that decision lived with each plugin author (default: distribute immediately) and each host (default: pass through). After June 5, the directory makes the default decision uniformly across 61,000+ plugins. Hosts that want a different trade can still build it on top of WordPress.org’s behavior: faster for trusted plugins, slower for high-risk categories, immediate for verified security patches. The platform’s default position, however, is now 24 hours.

Who Gets to Flip the Switch

Protect The Shire is a defensible technical decision. The way it was made is consistent with a pattern of unilateral WordPress.org actions over the past 18 months. In April 2026, Mullenweg called recent WordPress output “boring or mediocre crap” in the core committers Slack and overrode a committer-backed revert on Akismet’s inclusion in the WordPress 7.0 Connectors screen. In 2024 he proposed a royalty fee on selected commercial WordPress operators and launched the WordCamp US attack on WP Engine that is now in federal litigation. The Foundation dissolution motion that WP Engine filed in early 2026, with a hearing set for June 25, frames the underlying question: whether the WordPress trademark and the WordPress.org infrastructure should remain under the de facto control of a single CEO.

The 24-hour cooldown was not put through a community RFC, a Core Trac ticket, or a Make WordPress proposal. A blog post on June 5 announced a new default that every plugin author in the directory now operates under. AspirePress, a community project building a distributed WordPress package mirror with code signing, was started in fall 2024 as a structural response to single-point-of-failure concerns about the WordPress.org infrastructure. The EU Cyber Resilience Act, which creates an “open-source software steward” category covering organizations that maintain ecosystems like WordPress, introduces cybersecurity policy and vulnerability disclosure obligations that may eventually force the governance question from outside the project.