Security advisories on Drupal: what "applied" should mean

Short answer: a Drupal security update is applied when four things are true. The fixed release is in your site's code. It has been deployed through the same tested pipeline as any other change. Someone has checked the live site and seen it running the fixed version. And the decision is written down, with the advisory, the version and the date. "Merged" and "deployed" are steps on the way. Neither one is "applied".

How does Drupal publish security advisories?

The Drupal Security Team publishes them at drupal.org/security, in three lists: core, contributed projects, and public service announcements. You can follow them through the security newsletter in your drupal.org profile, by RSS, or on Mastodon and Bluesky.

They come at set times:

• Contributed modules have a release window every Wednesday.
• Core has one Wednesday a month, usually the third.
• Releases land between 16:00 and 22:00 UTC, which is 11:00 to 17:00 in Colombia.

A window does not mean a release will come. A highly critical issue can be released outside it.

Each advisory carries a risk level, scored from 0 to 25 on NIST's Common Misuse Scoring System. The five levels run from Not critical, through Less critical, Moderately critical and Critical, to Highly critical. Two recent core advisories:

• SA-CORE-2026-013 (16 September 2026): moderately critical, 13/25, in third-party libraries.
• SA-CORE-2026-014 (14 October 2026): critical, 19/25, remote code execution in the Field UI module.

Is every module covered?

No, and this is the part owners miss. For core, advisories cover the two most recent minor versions. Drupal 10 stops receiving them when it reaches end of life on 9 December 2026. For contributed modules, only stable releases of projects that have opted in are covered. Alpha, beta, release-candidate and development releases are not. A covered project shows a shield on its drupal.org page.

That includes our own work. Our founder's two modules on drupal.org, elevenlabs_agent and maper, are in their alpha series. When we read their pages on 27 October 2026, both said they were not covered. If your site runs a module like that, someone has to watch it another way: its issue queue, its releases, and a dependency audit.

Drupal's advisories also never cover what Drupal runs on. PHP publishes its own advisories, and so do the Composer libraries under Drupal. A composer audit reads the libraries' advisories; it does not read PHP's.

What should "applied" mean?

1. Released into your code. The site moves to the lowest fixed version on the branch it is on. A security update should not quietly become a minor-version upgrade. Afterwards, composer audit of the production dependencies comes back clean.
2. Deployed through the pipeline. Tests, the audit gate, an image build, the deploy, and a health check that the home page answers. Before any of it, a snapshot of the database and of the running image is taken, so rolling back is a known step, not an improvisation.
3. Verified on the live site. Someone reads the version the production site is running, and checks that the running image is the commit that was pushed. A health check proves that the site answers. It does not prove which version answered.
4. Recorded. The advisory, the version, the commits, the date and the snapshot, written where someone else can read them.

What does that look like on our own sites?

• The audit gate saw it first. When SA-CORE-2026-013 came out, every one of our sites' builds failed at the dependency audit before anyone had read the advisory. That is the gate doing its job. The five sites moved to Drupal 11.4.7, and on 18 September 2026 all five were recorded as running 11.4.7 on the live site.
• When you can't apply, mitigate, and say so. For SA-CORE-2026-014, one of our sites, Mon Petit Café, could not take the core update at once. Its audit gate was also failing on a moderately critical advisory in the Leaflet map module (SA-CONTRIB-2026-204), which we had chosen to leave open until our own map module replaced Leaflet. So on 15 October we uninstalled Field UI on that production site as a stop-gap, and recorded why. Leaflet left that site's code on 21 October.
• An exception needs a date to look at it again. In June 2026, this site's composer.json recorded two advisories in the guzzlehttp/psr7 library as ignored, with a written reason. Core then pinned that library to a range with no fix, and the site uses it only for outbound requests to known addresses, so no visitor controls the host that the vulnerable code reads. The note said: revisit when core moves to 11.4. Core has been on 11.4 since July, and the library is now on 2.13.2, past the fixed release (2.10.2). So the ignores no longer hid anything, but they were still in the file. We removed them on 31 October 2026, with a note saying why.
• PHP needed its own check. On 21 October 2026, PHP published fixes for two critical remote-code-execution flaws (CVE-2026-109618 and CVE-2026-109619). Our image's PHP 8.3 base had stopped at 8.3.29 in January, so no rebuild could pick up the fix. On 26 October we moved the image to PHP 8.4.27. The pipeline deployed it that evening, and the health check passed. On 31 October we read PHP 8.4.27 on the live site.

What do we promise when an advisory lands?

When you hire us to look after a site, an advisory that touches it gets a same-business-day start. We assess it against your site, apply the fix or mitigate it, check the live site from the outside, and write it down. That is a term of the engagement, not a measured record: we have not measured advisory-to-deploy times, and we won't quote one. Business hours are Colombian time (UTC-5), and there is no 24/7 on-call, because today the engineer is our founder. Before Tecnocratica, he ran a fleet-wide response to a Drupal core advisory across a healthcare fleet of about 400 sites.

What should you ask whoever patches your site?

• Which advisories did you assess this month, and what did you decide for each?
• Which modules on my site are not covered by the security advisory policy, and how are you watching them?
• How do you know the live site runs the fixed version?
• Where is the record, and could someone else read it?
• What do you watch besides Drupal: PHP, the libraries, the server image?

The monthly routine around these answers is in what a month of Drupal maintenance should actually check. To have your own site's modules and coverage reviewed, write to us or ask the concierge on the home page. Our offer explains how we take on a site.