Drupal security updates: a maintainer’s playbook

I sit on both sides of Drupal security: as a consultant applying updates to production sites, and as the maintainer of 24 drupal.org projects — which means I have also shipped security releases, coordinated with the Drupal Security Team, and seen what happens on the other side of the embargo. Here is how the machine works, and the routine I wish every site owner applied.

How Drupal security releases actually work

• Security advisories are scheduled. Core security releases land on Wednesdays, announced in advance through PSAs (public service announcements) for the critical ones. This is a gift: you can plan a maintenance window before knowing the details.
• Fixes are prepared under embargo. When a vulnerability is reported, maintainers work with the Security Team in a private queue. Nothing is public until the fix ships — which is why “the module looks quiet” tells you nothing about what is coming.
• Severity is scored, not vibes-based. Advisories carry a risk score (access complexity, user interaction, privileges required, data impact). A “Critical” with “no authentication required” is a drop-everything event; a “Less critical” needing an admin account can wait for the next cycle.
• Only covered releases get advisories. Modules without security-team coverage (alpha/beta releases, or projects that opted out) get no advisory at all — vulnerabilities are fixed silently or never. An abandoned contrib module is not “stable because it hasn’t changed”; it is unaudited attack surface.

The history lesson has a name: Drupalgeddon. In 2014 (SA-CORE-2014-005) and again in 2018 (SA-CORE-2018-002), sites unpatched after a critical advisory were compromised within hours of disclosure. Attackers read advisories too — publication is the starting gun.

The routine I apply to client sites

1. Know your Wednesday. Subscribe to the security newsletter and the RSS feeds; put the release windows in the team calendar. Surprises are for amateurs.
2. Patch time is severity-driven. Critical core/contrib with remote exploitation: same day, even if it means a hotfix deploy. Moderately critical: within the week. Everything else: the monthly maintenance train.
3. Automate the boring detection. composer audit in CI fails the build on known-vulnerable packages; Upgrade Status and dashboards catch the rest. A human should decide when to update, never whether to notice.
4. Update in the right order. composer update → drush updb → drush cr → automated smoke tests → deploy through the same pipeline as any release. Security updates that bypass CI are how you trade a vulnerability for an outage.
5. Audit the module list twice a year. Every module you can uninstall is attack surface, update work and audit scope removed. The cheapest patch is the module you no longer run.
6. Watch the meta-risks. PHP version EOL, unmaintained themes, and — the big one right now — Drupal 10’s end of support in December 2026. Running an EOL major means every future advisory is a fix you cannot apply.

What being a maintainer changed in my thinking

Shipping a security release for a module used by hundreds of thousands of sites teaches you two things. First, the fix is the easy part — the hard part is compatibility discipline, so that sites four minor versions behind can still take your security release without a migration project. That is why keeping your site routinely updated is itself a security control: it keeps the emergency path short.

Second, silence is not safety. I have watched issues sit in private queues for weeks while a fix was engineered. The site owners who were fine were the ones whose update pipeline was already warm.

Want your update pipeline audited — or a Drupal 7/9/10 site that nobody dares to touch brought back under maintenance? That is literally my job.