Drupal Security Advisory SA-CORE-2026-004 was published on May 20, 2026, scored 20 out of 25 on the project's NIST-style severity scale, with a SQL injection vector limited to PostgreSQL deployments. The same release bundles coordinated security patches across Symfony and Twig that apply to every Drupal site regardless of database driver.

What happens in the hours after a Drupal security advisory drops decides whether the site is patched within the response window the severity score demands. The work breaks down into four operational moments: subscription, assessment, staging, and deploy. This article walks through each.

How to determine whether an advisory affects your site

Every Drupal security advisory specifies which sites are exposed. Triage runs through three questions in order:

  1. Is your Drupal core version supported? Advisories list affected version ranges and the patched releases for each supported branch. End-of-life branches receive best-effort patches but no long-term coverage, so a deployed mitigation should be paired with an active upgrade plan.
  2. Does the configuration scope apply to you? Some advisories affect every Drupal site; others depend on which subsystem you use. Database driver, contrib modules, role permissions, and theme behavior are all common scoping dimensions to check in the advisory text.
  3. What upstream dependencies are bundled? A Drupal core security release typically bundles patches for Symfony, Twig, and sometimes Composer. Even when the headline vector does not apply to your configuration, the bundled upstream fixes usually do.

SA-CORE-2026-004 makes the second and third questions concrete:

  • Sites on PostgreSQL. Directly affected by the SQL injection vector. Patch within 24 hours; this is the response window the 20-out-of-25 severity score is calibrated for.
  • Sites on MySQL or MariaDB. Not affected by the SQL injection vector itself, but the coordinated Symfony and Twig security patches apply universally and ship in the same Drupal core release. Patch within the standard 48-hour window for highly critical advisories.
  • Sites on Drupal 8.9 or 9.x. End-of-life branches. Patches are best-effort from the Drupal Security Team and any deployed mitigation should be paired with an active upgrade plan to a supported branch.

What a Drupal security advisory contains

A Drupal Security Team advisory follows a structured format: a severity score on a NIST-style 25-point scale, a precise description of affected versions and configurations, the list of bundled upstream dependency updates, and named credit to the reviewers and reporters. The format is the same whether the advisory affects one module or all supported branches, which makes triage on the day of release predictable. SA-CORE-2026-004's own text is a useful example:

A vulnerability in this API allows an attacker to send specially crafted requests, resulting in arbitrary SQL injection for sites using PostgreSQL databases. This vulnerability can be exploited by anonymous users.

Two sentences, three load-bearing facts: the vector class, the configuration in scope, and the authentication boundary. That is the level of precision the Drupal Security Team applies to every release. The 25-point scoring rates four dimensions, and a 20-out-of-25 rating like SA-CORE-2026-004 means the vector is reachable by unauthenticated requests and impacts both confidentiality and integrity. That combination is the difference between an advisory you patch in maintenance and an advisory you patch tonight. The supported-version matrix also matters: Drupal security coverage tracks active minor releases and the End of Life calendar, and our Drupal 10 end-of-life migration guide walks through how those lifecycle dates interact with major upgrade planning.

The four moments that decide whether your site is safe

1. Subscription

Subscribe to Drupal Security Team advisories via RSS and email so your team learns about a new advisory within hours, not days. Route the same feed to your incident-response channel: Slack, Teams, or a dedicated alias. The goal is that the first person to read a new advisory is not the one who hears about it from a news cycle 36 hours later. A second feed worth tracking is the Drupal Public Service Announcement (PSA) stream, which announces the timing of upcoming critical advisories so teams can pre-allocate response capacity before the patch lands. PSA-2026-05-18 announced SA-CORE-2026-004's timing three days in advance, which is the standard pattern for highly critical releases.

2. Assessment

Read the advisory carefully to determine whether your configuration is in scope, because database driver, contrib modules, role permissions, and version branch all gate exposure. SA-CORE-2026-004 is a clean example of why this matters: a 20-out-of-25 advisory that only directly affects PostgreSQL sites, with bundled upstream patches that apply universally. Triage produces a decision: emergency patch tonight, standard patch within 48 hours, or a deferred update synchronized with the next maintenance window. Document the decision and time-stamp it. Skipping this step is how teams either overreact to advisories that do not affect them or miss ones that do.

3. Staging and testing

Apply the patch on a staging environment that mirrors production, then run the full regression test suite before any production deploy. Even a one-line core fix can interact with custom modules, theme overrides, or contrib code, and the day of a security advisory is exactly the wrong time to discover an interaction in production. Staging must run current production data (or a recent representative copy), the same PHP and database versions, and the same contrib module list. If staging diverges from production in any of those dimensions, the test result on staging does not generalize.

4. Deploy with rollback readiness

Deploy atomically with a pre-deploy database backup in place, then verify the patch is live and your rollback procedure is one command away. Atomic deploy means production never sees a partial state: code, configuration, and database migrations all move together, or none of them do. Pre-deploy backup is the safety net for the small percentage of patches that touch data in unexpected ways. Post-deploy verification means loading the affected endpoint and confirming the vulnerability is closed, not just confirming the new release tag is in place.

The dependency cascade most people miss

When you update Drupal core, you are also moving Twig, Symfony, and sometimes Composer in lockstep, because Drupal's release process is coordinated with its upstream maintainers.

A Drupal core security release is rarely just a Drupal release.

SA-CORE-2026-004 shows this cleanly: the same composer.lock change that bumps drupal/core from 11.3.9 to 11.3.10 also moves twig/twig from 3.22.2 to 3.26.0 (a four-minor-version jump that includes multiple sandbox bypass and XSS fixes), along with thirteen Symfony components moving to 7.4.11 or 7.4.12. Each upstream change carries its own security fixes, documented separately by the respective project. The advisory itself makes this explicit:

Updating these dependencies is highly recommended whether the SQL Injection vulnerability affects you or not. It is also recommended to review which user roles have the ability to update Twig templates.

The Symfony security advisory stream publishes the specifics for any Symfony component bumped in a Drupal release. Treating the bundled release as a single coordinated security event, not as a Drupal update with incidental dependency changes, is what separates a robust patching process from a brittle one.

Signals you have the wrong maintenance partner

Most maintenance failures are not dramatic. They show up as small operational gaps that accumulate until an advisory like SA-CORE-2026-004 puts pressure on the gaps and they break. The diagnostic symptoms:

  • Advisories caught by the news cycle, not by an internal feed.
  • Patches deployed three or more days after a highly critical advisory, regularly.
  • No staging environment, or a staging environment that does not match production.
  • No rollback procedure documented, or a procedure that nobody has rehearsed.
  • "It is fine, we have not had a problem yet" cited as evidence that the Drupal security update process works.

The last one is the most reliable signal. The absence of incidents is not evidence of a robust process; it is evidence that no advisory has yet exercised the gaps.

Frequently asked questions

Is my Drupal site affected by SA-CORE-2026-004?

Sites on PostgreSQL are directly affected by the SQL injection vector in SA-CORE-2026-004. Sites on MySQL or MariaDB are not exposed to that specific vector. However, every Drupal site running an affected version (Drupal 8.9 through 11.3.9) receives bundled Symfony and Twig security patches in the same release, so the update applies universally regardless of database driver.

Do I need to update Drupal if I use MySQL?

Yes. The SQL injection vector only affects PostgreSQL, but the same release ships coordinated Symfony and Twig security patches that apply universally. Sites on MySQL or MariaDB should still patch within the standard 48-hour window for highly critical advisories.

What is the difference between a Drupal PSA and an SA?

A Public Service Announcement (PSA) gives advance notice one to three days before a major advisory, without disclosing the vulnerability. A Security Advisory (SA) is the technical document you act on, with affected versions and patched releases. PSAs let teams pre-allocate response time; SAs are what you patch against.

How fast should a Drupal site be patched after a critical advisory?

Highly critical advisories (20 or higher on the 25-point scale) should be patched within 24 to 48 hours of publication, because exploits typically appear within hours of public disclosure. Moderately critical advisories warrant patching within a week. Sites running custom code that interacts with the affected subsystem may need additional staging time.

What does the Drupal Security Team release process look like?

The Drupal Security Team is a volunteer-staffed but professionally operated team that reviews incoming security reports, coordinates patches with Drupal core maintainers and upstream projects (Symfony, Twig, Composer), and publishes structured advisories with NIST-style severity scoring. Each advisory credits the reporter and reviewers by name, ships matched patches across affected versions (with best-effort coverage for end-of-life branches), and is timed to coordinate with upstream security releases. The team's public process documentation lives at drupal.org/drupal-security-team.

Putting it into practice

The four moments compress to a few hours of focused work once a team has run them a few times, and the Drupal Security Team's release cadence is reliable enough to plan around. The process is the value, not the heroics of a single response. If your team does not run something like this today, we run it on retainer as part of our Drupal maintenance service.