WordPress.org update delay cut to six hours

#Update, 28 July 2026: the cooldown is now six hours

The mandatory cooldown on WordPress.org plugin and theme auto-updates has been cut from 24 hours to six. Konstantin Obenland, an Automattic-sponsored contributor, posted the change in the #meta channel on WordPress Slack, and The Repository carried it in issue 312 on 24 July 2026.

Six hours is not the destination. Per the same update, work is underway to skip the delay entirely when the AI reviewer, named Gandalf, finds no issues, which should shorten the wait to minutes for the majority of updates.

Everything below this section was written while the delay was 24 hours, and it stays as the record of what that policy cost. Read the original numbers as the “before”. The exposure window it describes is now a quarter of the size and shrinking, but the shape of the problem has not changed: a public code diff sitting behind any hold is still a head start for whoever reads it first, and an agency that can pull a tagged release from Git waits for neither six hours nor 24.

#Introduction

The June 2026 decision by the WordPress.org plugins team to implement a 24-hour update delay sparked intense debate among developers and site administrators. Although this mechanism was announced as protection against automatic updates following recent supply chain compromises (such as the plugin CDN breach at Awesome Motive), its actual reach proved much larger. The cooldown applied to all updates - including those triggered manually from the dashboard. As of 24 July 2026 the hold is six hours, and the plugins team is working toward removing it for releases the Gandalf review clears.

For web agencies and teams maintaining large B2B sites, the change introduced a significant security risk. The moment a developer publishes a security patch, the changelog becomes public. Hackers and botnets can analyze the code immediately and launch attacks, while site administrators were blocked from updating for a full day. That block is now six hours. Let us look closer at the mechanism and see how we can secure our projects outside the official WordPress.org directory, on either clock.

#The vulnerability window: Bots have a head start over administrators

The primary problem reported by the community is information asymmetry. Miriam Schwab from Elementor pointed out on Slack that this delay creates an ideal window for automated attacks. Under normal circumstances, the reaction time to a critical vulnerability (e.g. SQL Injection or Remote Code Execution) is measured in minutes. When the patch is available, agencies run WP-CLI scripts or management systems (e.g. MainWP, ManageWP) for immediate deployment.

Under the rule as introduced, installation was blocked by WordPress.org for 24 hours after the code was submitted by the plugin author. The hold is now six hours, and the asymmetry survives the cut: the code is visible in the public SVN or GitHub repository from the moment it is submitted. Bots can detect vulnerable versions and attack sites before the owners have the opportunity to click “Update”.

Another problem is the resetting of the timer. If a developer detects an error right after release and issues a new fix (e.g. version 1.0.1 a few hours after 1.0.0), the cooldown restarts. Under the 24-hour rule that could push the wait for stable code out to 48 hours. Obenland’s post announcing the cut to six hours says nothing about the reset behaviour, so treat it as unchanged until the plugins team says otherwise.

#Impact of the delay on security processes

Compare the classic update model, the delay as introduced, and the policy in force today:

#How to configure private Composer repositories for WordPress security updates

To avoid the WordPress.org update cooldown for critical security patches, six hours today and 24 before the July change, agencies should manage plugin dependencies via Composer. Here is a production-ready configuration using wpackagist and private GitHub repositories.

To maintain full control of the update process and bypass the WordPress.org delay, we recommend managing plugin dependencies via Composer. This makes it possible to fetch code directly from trusted sources (e.g. the developer’s GitHub repository) before its approval in the official directory.

Here is a production-ready composer.json for a secure B2B site:

{
  "name": "wppoland/b2b-secure-site",
  "description": "Production-ready Composer configuration bypassing WordPress.org update cooldown",
  "repositories": [
    {
      "type": "composer",
      "url": "https://wpackagist.org"
    },
    {
      "type": "vcs",
      "url": "https://github.com/elementor/elementor"
    }
  ],
  "require": {
    "composer/installers": "^2.0",
    "johnpbloch/wordpress-core": "^6.9",
    "wpackagist-plugin/contact-form-7": "^5.9",
    "elementor/elementor": "dev-master"
  },
  "config": {
    "allow-plugins": {
      "composer/installers": true,
      "johnpbloch/wordpress-core-installer": true
    },
    "preferred-install": "dist"
  }
}

With this configuration, in case of critical failures in Elementor or other plugins with a VCS repository, we can download the code directly from the indicated branch on GitHub, before the WordPress.org hold expires.

#Technical aspects of Composer implementation in large environments

Integrating Composer to bypass the update delay requires changes to the agency’s DevOps workflows. Setting up a local Satis server enables deploying updates immediately without delay.

Here is a production-ready satis.json configuration file for agencies:

{
  "name": "wppoland/agency-repository",
  "homepage": "https://satis.wppoland.dev",
  "repositories": [
    {
      "type": "vcs",
      "url": "https://github.com/elementor/elementor"
    },
    {
      "type": "vcs",
      "url": "https://github.com/wp-premium/contact-form-7"
    }
  ],
  "require": {
    "elementor/elementor": "*",
    "wpackagist-plugin/contact-form-7": "*"
  },
  "require-dependencies": true,
  "archive": {
    "directory": "dist",
    "format": "zip",
    "skip-dev": true
  }
}

This reduces the security window and allows teams to react as soon as a patch is published on GitHub, completely removing the dependency on the official WordPress.org directory.

Comparing SVN-based and Git-based distribution reveals significant differences in speed and pipeline integration. Git allows automated testing, linting, and semantic versioning bounds, giving agencies complete confidence in the integrity of emergency updates.

#Deep dive: The evolution of WordPress supply chain attacks in 2026

In 2026, supply chain attacks targeting the WordPress ecosystem have intensified. Malicious code injection prompted WordPress.org to introduce radical security measures.

The delay provides time for automated malware scanning. The cut from 24 hours to six is the plugins team’s answer to the complaint that a full day was too much of that time to buy, and the planned bypass for releases the Gandalf review clears goes further. Six hours is still six hours when the patch is CVSS 9.0+.

For B2B sites, reaction speed is vital. We recommend pulling the patch directly from the developer’s Git repository to bypass the official directory’s cooldown period. This protects against obfuscated malware that bypasses traditional scanners. Additionally, setting read-only permissions (chmod 555) on the server’s plugin directory protects the files from unauthorized modification.

Agencies must establish a structured SecOps Incident Response Protocol: 1. Block exploit paths at the WAF level. 2. Fetch/build the patch from Git. 3. Deploy via Composer pipelines. This workflow ensures that client sites are secured in minutes rather than days.

#Practical deployment script for immediate B2B security patches

In emergencies, developers can use a bash script with WP-CLI to deploy updates directly from GitHub:

#!/usr/bin/env bash
# Emergency patch deployment bypass via WP-CLI
set -euo pipefail
PLUGIN_NAME="contact-form-7"
GITHUB_REPO="dQw4w9WgXcQ/contact-form-7"
TARGET_VERSION="5.9.6"
WP_PATH="/var/www/html"
curl -sSL -o "/tmp/patch.zip" "https://github.com/${GITHUB_REPO}/archive/refs/tags/v${TARGET_VERSION}.zip"
wp plugin install "/tmp/patch.zip" --path="${WP_PATH}" --force --activate
wp cache flush --path="${WP_PATH}"

To automate this process within a GitHub Actions workflow, use the following configuration:

name: Emergency Patch Deployment
on:
  push:
    branches:
      - main
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repository
        uses: actions/checkout@v4
      - name: Install SSH key
        uses: shimataro/ssh-key-action@v2
        with:
          key: ${{ secrets.SSH_PRIVATE_KEY }}
          known_hosts: ${{ secrets.SSH_KNOWN_HOSTS }}
      - name: Run remote deployment via SSH
        run: |
          ssh [email protected] "bash -s" < ./scripts/deploy-patch.sh

This script ensures B2B sites can be patched immediately without waiting for WordPress.org directory approval. It minimizes human error during emergency situations under extreme pressure.

#Technical guide: WAF rule configuration for zero-day vulnerability mitigation before patch release

When a critical zero-day vulnerability is publicly disclosed and agencies must wait out the WordPress.org update cooldown, six hours since 24 July 2026, implementing emergency Web Application Firewall (WAF) rules is the most effective temporary shield. Below is the technical configuration for Nginx and Cloudflare.

#1. Nginx WAF Rule Configuration (Server-Level Mitigation)

If the vulnerability targets a specific plugin’s AJAX handler (e.g. wp_ajax_nopriv_update_settings), you can intercept and drop these requests directly in Nginx, preventing them from hitting PHP-FPM:

location = /wp-admin/admin-ajax.php {
    if ($arg_action = "update_settings") {
        return 403;
    }
    if ($request_body ~* "action=update_settings") {
        return 403;
    }
    include fastcgi_params;
    fastcgi_pass unix:/var/run/php/php8.1-fpm.sock;
}

#2. Cloudflare Custom WAF Rule (Edge Mitigation)

For sites proxied by Cloudflare, block malicious payloads at the edge using Cloudflare WAF Custom Rules. Below is the JSON representation of the WAF rule:

{
  "action": "block",
  "expression": "(http.request.uri.path eq \"/wp-admin/admin-ajax.php\" and (http.request.uri.query contains \"action=update_settings\" or http.request.body.raw contains \"action=update_settings\"))",
  "description": "Emergency block for vulnerable AJAX action update_settings before patch cooldown expires"
}

#3. Access Log Forensics

To audit whether client sites were targeted or compromised before WAF rules were applied, run the following search command on your access logs:

grep "POST /wp-admin/admin-ajax.php" /var/log/nginx/access.log | grep -E "action=update_settings|update_settings"

Implementing these temporary layers, server blocks, edge filtering, and log auditing, secures B2B WordPress installations while bypassing the delivery restrictions of the official directory.

#Case Study: Zero-day incident response for a high-volume WooCommerce store

To understand what the 24-hour delay cost while it was in force, let us examine an actual security incident handled by our team in June 2026, weeks before the cut to six hours. The client, a leading fashion eCommerce store, relies on WooCommerce and a premium shipping integration plugin. At 14:00, a critical SQL Injection vulnerability was publicly disclosed in the shipping plugin, allowing unauthenticated database extraction.

For a high-volume online store, taking the site offline or leaving it exposed for hours is a catastrophic scenario. Due to the cooldown policy as it stood that month, the secure version 4.2.1 was held back, the dashboard updater estimated the patch would not be installable for another 24 hours.

#Our step-by-step incident response and mitigation workflow:

1. Patch Source Inspection: Our SecOps team immediately located the developer’s public GitHub repository and reviewed the code diff between version 4.2.0 and 4.2.1. This validated that the patch was clean and correctly parameterized the SQL query.
2. Edge WAF Blocking: Minutes after disclosure, we deployed a custom Cloudflare WAF rule to block all POST requests targetting the vulnerable API endpoint. This neutralized the immediate threat vector while we prepared the package deployment.
3. Composer VCS Integration: Because our architecture utilizes Composer for dependency management, we modified the project’s composer.json file to target the v4.2.1 tag on GitHub directly, bypassing the WordPress.org plugin directory.
4. Automated Staging Testing: The CI/CD pipeline checked out the new dependency config, ran integration tests, and simulated checkout flows to confirm the update did not conflict with custom payment gateways.
5. Production Deployment: Well inside the first hour after the vulnerability announcement, the secure version 4.2.1 was active on production servers.

By implementing a modern deployment stack built around Composer VCS and edge firewalls, we cut the zero-day exposure window from a full day to a fraction of an hour. Relying on default WordPress updates would have left the client’s database exposed to automated bots for a full 24 hours. The same incident today would cost six hours on the default channel, which is better arithmetic and the same decision: a decoupled pipeline beats both. This case study demonstrates why enterprise B2B environments must decouple their deployment channels from the official directory distribution.

#Expert Opinion & B2B Strategy: Automatic vs. Manual Plugin Updates in Enterprise Sites

The update delay, 24 hours as introduced and six since July 2026, re-opened the broader debate on update management strategy for B2B and enterprise-scale websites. While auto-updates are a cornerstone of WordPress.org’s security posture for millions of simple blogs and small business cards, they present a significant operational risk for custom-built enterprise portals.

PublishPress founder Steve Burge notes that the review cooldown has actually proved useful. According to him, the automated security scanners run by the plugins team caught minor issues in their update packages that their internal team missed. This indicates that the review phase offers immediate defensive value by auditing code before it reaches dashboards. However, in B2B environments, this does not override the fundamental rule that production code must be audited and tested before deployment.

#Strategic B2B Security Guidelines for Web Agencies:

1. Disable Automatic Updates in Production: Production environments must never auto-update core or plugins. Disable updates using the following constants in wp-config.php:

   define('WP_AUTO_UPDATE_CORE', false);
   define('AUTOMATIC_UPDATER_DISABLED', true);

2. Implement Automated Integrity Scans: Since updates are handled manually or through deployment pipelines, verify core and plugin checksums regularly via cron-based WP-CLI tasks:

   # Verify core WordPress integrity
   wp core verify-checksums
   # Verify checksums for all official plugins
   wp plugin verify-checksums --all

3. Enforce Restrictive Content Security Policies (CSP): To protect users in the event that a malicious package bypasses review and is deployed, enforce a strict CSP on Nginx or Apache. This prevents the browser from executing unauthorized third-party scripts or performing unauthorized data extraction (data exfiltration) even if the plugin database payload is compromised.

#Checklist: How B2B agencies should react to the changes

Adopting the following measures will minimize the risk associated with the new mechanism:

1. Supply chain audit: Identify business-critical plugins and those that had vulnerabilities in the past.
2. Migration to Composer: Manage important plugins through Composer and VCS repositories (such as GitHub, GitLab).
3. Use WP-CLI for immediate patches: If a vulnerability is exposed, install the ZIP directly via WP-CLI:

   wp plugin install https://github.com/vendor/plugin/archive/refs/tags/v1.0.1.zip --force

4. Monitor changelogs: Track services like WPScan or Patchstack for early detection of vulnerabilities.
5. Use staging environment: Always test manual installations in staging before applying them in production to avoid downtime.

#Summary

The update delay was always a trade-off between security and functionality, and the plugins team has now repriced it: 24 hours became six on 24 July 2026, with a route planned to skip the wait altogether once the Gandalf review clears a release. The criticism in this piece did its job, and most of the cost it described is gone.

What survives the cut is the workflow. A six-hour hold on a public code diff still hands the first move to whoever reads the diff fastest, and a B2B site with a CVSS 9.0+ bug in a shipping plugin should not be waiting on any queue. Composer with VCS sources, checksum verification, and WAF rules as the stopgap remain the standard for professional WordPress agencies, and they will keep working whatever the number becomes next.