When a Drupal security release lands

A Drupal security release is a deadline you do not set. Exploits for a critical one can appear within hours, so the useful question on release evening is short: which of my sites carry the affected code, and how do I get fixed code under them tonight without breaking anything.

This page covers Drupal 8 and newer, the Composer-managed codebases. It walks the evening in order: when the release arrives, who covers which layer, the checks you can run without unlocking anything, and the route that puts fixed code under your sites the same evening.

When releases arrive, and which email to act on

Drupal publishes security releases on Wednesdays: contributed projects in any week, Drupal core on one Wednesday a month (usually the third), between 16:00 and 22:00 UTC. A highly critical fix may also ship outside that window. The schedule is drupal.org's release timing policy.

For a critical release the security team announces a narrower window a few days ahead, in a public service announcement (PSA). Drupal core's critical release of 20 May 2026 (PSA-2026-05-18) and a widely used contributed module's of 23 September 2026 (PSA-2026-09-21), for example, both used 17:00 to 21:00 UTC.

Inside that window the advisories may be published one by one, and the mailing-list emails go out together at the end of it. Act on that end-of-window email, not on the first advisory you happen to see: it is the complete list, and it names every affected project and fixed release.

Who covers which layer

A BOA box has three layers of code, and a security release touches each in a different way.

• The server stack is BOA's. With SKYNET on (the default), BOA refreshes its own tools, monitors and self-healing agents every five minutes, and the operating system's security updates install themselves. A new BOA release is a separate step — see Keeping BOA current.
• Your Drupal 8+ codebase is yours (or, on a Managed plan, ours). BOA cannot apply these patches automatically: Drupal 8+ codebases are Composer-managed, and patching core or a module outside Composer breaks the codebase's integrity and cannot be safely automated across every project without someone reviewing it. On a Managed plan applying security releases to your codebase is the service, the same day as current practice.
• The platforms BOA provides are not for production. The distributions (Drupal CMS, Varbase, LocalGov and the rest of the distribution catalogue) and the plain Drupal 9, 10 and 11 cores are for demonstration and compatibility testing only. Their security updates are best effort: BOA does not chase Drupal security releases for them.

That last point deserves a sentence of its own. A box fetches a provided platform only while its directory is absent, so a platform already on your box keeps the code it was first fetched with, and newer code arrives only with a later BOA release, under a new platform name. Production sites belong on a platform you build and own in ~/static, which is also what the route below updates.

Check tonight, without unlocking anything

These checks only read. None of them needs the local Drush unlocked, and none of them changes a byte of code.

• In the site, as its administrator: Reports → Available updates (with the core Update Manager module enabled) lists every module and theme with a newer release, security releases flagged.

• In your shell, as oN.ftp, from the platform's app root (the folder with composer.json):

  SHCopy

  composer audit --locked       # every known advisory affecting the locked packages
  composer outdated drupal/*    # every Drupal package with a newer release
  

composer audit --locked checks the exact versions your platform shipped with against the published advisories and prints each advisory's ID, package and affected range. Its answer counts only when the platform's composer.json declares drupal.org's repository, https://packages.drupal.org/8 — any codebase with Drupal contributed modules does. Without it Composer never sees drupal.org's contributed-module advisories and reports a clean platform that is not.

composer outdated drupal/* is the survey of what is behind, covered with the other build helpers in Build a platform.

Drush's own security check needs the unlock

The site's bundled Drush can run the same check through drupal.org's advisories, but only with the platform's local Drush unlocked. Run the Unlock Local Drush task on the platform in the control panel first, then:

vdrush @example.com pm:security

Run Lock Local Drush again when you are done. The composer audit check above answers the same question and needs no unlock, which is why it comes first on this page. Drush basics covers vdrush and its aliases.

The same-evening route: a fresh platform, then Migrate

Never composer update a platform that live sites run on. The fix goes into a new platform beside the old one, and your sites move across with Ægir's Migrate task:

1. Build a fresh platform in ~/static with the fixed release required explicitly, for example composer require drupal/module_name:^1.8 --update-with-dependencies (Build a platform has the full recipe).
2. Register it as a new platform.
3. Migrate one test or staging site onto it and check it works.
4. Migrate the rest, then retire the old platform when nothing runs on it.

The old platform stays exactly as it was, so a site that misbehaves on the new one migrates straight back. Cloning and migrating sites covers the Migrate task itself.

A site that still runs on a platform BOA provides takes the same route, and for good: rebuild your own copy of the distribution or core in ~/static with the fixed release, and migrate onto it.

Related

• Build a platform — the Composer build and the helpers that bring modules up to date.
• In-place upgrades — why updating a live codebase in place is the route to avoid.
• Distributions — the catalogue BOA installs for you, for demonstration and compatibility testing.
• Security on your box — what BOA hardens by itself on a self-hosted box.
• Keeping BOA current — the stack side: SKYNET and BOA releases.