Why WordPress.org Plugin Updates Can Now Take Six Hours

WordPress.org now runs an automated security review on every plugin release before distributing it through the update API. The review happens inside the existing release cooldown, which has applied to plugin and theme releases since June 5 and is currently six hours.

The September 9 change is not the cooldown itself. It is the automatic security gate inside that window: a release assessed as high risk can now be blocked from the update API as soon as the review finishes.

1. The release enters cooldown. WordPress.org holds it before distribution through the update API, including one-click updates in wp-admin.
2. Automated checks analyze the changes. WordPress.org says several AI models and Jetpack Scan review the release, then combine and cross-check their findings into a security score.
3. Lower-risk releases continue normally. Authors do not need to take action simply because the release is in cooldown.
4. High-risk releases are blocked. Distribution through the update API stops, and every plugin committer receives an email describing the findings.

A high score measures potential risk, not intent. An accidental vulnerability can trigger the same block as deliberately harmful code. False positives are possible, even though the results are cross-checked.

The automated review is a final distribution gate, not a substitute for release engineering. Before every WordPress.org tag:

• Run the complete quality suite. Use Plugin Check, coding-standard checks, static analysis, automated tests, and the plugin's manual regression checklist.
• Review security-sensitive changes manually. Pay particular attention to capabilities, nonces, input validation, sanitization, escaping, database queries, remote requests, file operations, uploads, deserialization, and dynamic code execution.
• Inspect dependency and build changes. Confirm that generated assets and bundled libraries contain only the files intended for the release.
• Test the packaged artifact. Install the exact release package on a clean staging site instead of testing only the development checkout.
• Check committer email access. Every committer should be able to receive and act on a block notification.

Schedule the tag at least six hours before the public launch time. Avoid promising that the update is available until it can actually be retrieved through WordPress.org's normal update path.

• Confirm that the intended tag and readme changes were committed correctly.
• Watch the email accounts attached to all plugin committers.
• Do not create extra tags merely because the release has not appeared in the update API during the cooldown.
• After the window, verify the public version, download, changelog, compatibility metadata, and update notice before announcing the release.

WordPress.org currently sends review email only when a release is blocked. No email generally means there is no action to take, but authors should still verify distribution rather than treating silence as proof that the update is live.

1. Read the findings carefully. Identify the code, behavior, or packaged file that raised the score.
2. Reproduce and correct the issue. Review nearby code for the same weakness and rerun the full release suite.
3. Publish a corrected release. WordPress.org says this is usually faster than waiting for a manual appeal. The replacement release enters the normal cooldown and security review.
4. Contact the Plugins Team when necessary. If the finding appears incorrect, provide a concise technical explanation and evidence without exposing secrets or customer data.

The six-hour window applies to updates for TranslateGuard for WooCommerce, Cobalt Checkout Diagnostics for WooCommerce, and CacheSafe for WooCommerce.

Our release checklist includes Plugin Check, coding standards, static analysis, automated tests, manual review of security-sensitive changes, and verification of the packaged plugin. Release notes and website version updates should follow WordPress.org distribution rather than the moment a tag is committed.

This process does not guarantee that a plugin has no vulnerabilities. It adds another useful security gate between a release and the sites that receive it.

Browse Cobalt Branch Labs field guides →

• Finish code, security, package, and staging checks before tagging.
• Commit the release at least six hours before the planned announcement.
• Monitor all committer inboxes for a blocked-release email.
• If blocked, fix the cause and publish a corrected release.
• After cooldown, verify the version through the WordPress.org update path.
• Only then update the website, release notes, and distribution channels.