WordPress.org quietly shipped one of the more consequential supply-chain security changes the ecosystem has seen in years. A new 24-hour cooldown period now sits between every plugin and theme release and the auto-update mechanism — and the stated goal is nothing less than securing all 78,000-plus packages in the repository. It's worth understanding what changed, why it matters, and what agencies running client sites should do in response.
What shipped
The initiative, which WordPress.org is calling "Protect The Shire," introduces a mandatory 24-hour holding period for every new plugin and theme version published to the official repository before it becomes eligible for automatic updates on live sites.
Previously, a plugin author — or a bad actor who had compromised a plugin author's account — could push a malicious release and have it flowing into auto-update queues within minutes. The window for a supply-chain attack was essentially the time it took for the WordPress.org review team to notice and react. That's not a comfortable margin when you're talking about 78,000 packages and a relatively small team of volunteers.
The 24-hour buffer changes the math in two important ways. First, it gives the WordPress.org security team, the community, and automated tooling time to flag anomalous releases before they propagate to millions of sites. Second, the announcement is explicit that AI tooling will be brought in to give defenders a systematic edge in reviewing releases at scale — pattern detection, anomaly scoring, and flagging for human review. The team is framing this as the first step in a longer effort to harden the entire repository, not a one-and-done fix.
For plugin authors and maintainers, the practical change is straightforward: expect a delay between tagging a release and seeing it appear in auto-update queues. Patch releases for critical bugs will still take a full day to roll out automatically. That's a reasonable trade-off.
Our take
This is a genuinely good move, and we think it's overdue — but it's also worth being clear about what it doesn't fix.
What it does fix: The most dangerous attack vector in the WordPress ecosystem right now is not a zero-day in Core. It's compromised plugin accounts. A credential stuffing attack or a phishing hit against a plugin maintainer can hand an attacker publish rights to a package with millions of active installs. The 24-hour window dramatically reduces the blast radius of that kind of incident. If malware ships in a release, the security team now has a realistic window to pull it before auto-updates fire. That's a meaningful improvement.
What it doesn't fix: The cooldown only applies to the auto-update pipeline. Sites that manually update immediately will still get whatever's in the repository the moment it lands. If your team has a workflow that involves clicking "Update" on plugin releases the day they drop — and plenty of diligent admins do — the protection disappears. The 24-hour buffer only helps if you're relying on auto-updates or at least waiting a day.
The AI-assisted review angle is worth watching. WordPress.org is signaling that manual review of 78,000 packages isn't sustainable, and that AI tooling is the path to scaling coverage. We think that's the right call, but it's early. AI-based anomaly detection is only as good as its training data and its false-positive rate — if the tooling flags too aggressively, release velocity for legitimate maintainers suffers. We'll be watching how this plays out over the next two or three release cycles.
For agencies, the honest implication is this: the 24-hour cooldown should reinforce a discipline we already recommend — don't rely on auto-updates as your only update strategy. Auto-updates are a reasonable backstop for low-traffic, low-complexity sites where the cost of a brief incompatibility is low. For client production sites with custom blocks, WooCommerce, active membership systems, or complex ACF setups, staged updates through a staging environment are still the right approach, full stop. The cooldown buys you more time in a crisis; it doesn't replace a proper update workflow.
One more thing: this is a reminder of how much surface area the contributed ecosystem represents. Core gets enormous scrutiny. Plugins get comparatively little. With 78,000 packages in scope, even a well-resourced security team is working at scale that's hard to fully audit manually. The move toward automated review is the right structural response, and we're glad to see the WordPress.org team pursuing it.
What to do now
- Review your auto-update settings on every site you manage. Understand which plugins are set to auto-update and whether those plugins have active, credible maintainers. If a plugin's last human-authored commit was two years ago, auto-update is a liability more than an asset.
- For production sites, add a one-business-day lag to your update workflow even beyond the auto-update window. Let the community surface compatibility issues before you apply.
- Subscribe to the WordPress Security feed at wordpress.org/news/category/security/ — this is the fastest way to hear when a compromised release gets pulled, even within the 24-hour window.
- For high-value sites, consider a plugin audit. If you're running more than 25 active plugins and haven't reviewed maintainer health in the past year, now is a good time. Abandoned plugins with broad permissions are exactly the kind of target this initiative is trying to protect against.
The direction WordPress.org is heading — AI-assisted review, release delays, systematic coverage of the full repository — is the right one. Getting there will take time and iteration. In the meantime, a disciplined agency-side update workflow remains your best line of defense.
Originally referenced: Protect The Shire on WordPress.org.
If you manage WordPress sites in production and want help auditing your plugin stack or tightening your update workflow, get in touch.
Originally published by WordPress.org. Read the full announcement here.
