On May 20, 2026, the Drupal Security Team published the critical vulnerability CVE-2026-9082. While the SQL injection only targets PostgreSQL infrastructures, this emergency update also includes universal fixes for 13 Twig vulnerabilities and 35 Symfony CVEs.
For those who have followed Drupal for many years, the announcement on May 18, 2026 revealing a critical vulnerability (rated 20/25 on the Drupal security team's risk scale) sounded like a very bad memory.
The last three times the security team had communicated in this way were in 2014 and 2018 regarding vulnerabilities dubbed the “Drupal Armageddon,” or Drupalgeddon. These vulnerabilities were so critical that it was predicted an attacker could understand them and code an exploit within hours.
Have we experienced a fourth Drupalgeddon? The purpose of this article is simple: to lay out the facts, specify the exact scope of impact, and give technical teams and decision-makers the elements to act in a proportionate manner.
A security update that hides another one.
The first point to emphasize is that when Drupal's security updates were released, they did not only address the vulnerability announced on May 18th. These updates included a second, equally critical update: a TWIG update that patched 13 vulnerabilities in the template engine (2 critical and 3 high).
Let's return to the two elements of these releases.
The Drupal vulnerability SA-CORE-2026-004: an SQL injection in the DB abstraction API
The vulnerability lies in the Drupal Core database abstraction API . This layer, fundamental to the CMS architecture, is specifically designed to sanitize queries sent to the database to prevent SQL injections.
A flaw in the protection mechanism allows an attacker to send a specially crafted query that bypasses this protection and leads to arbitrary SQL injection . Two characteristics make the vulnerability particularly sensitive:
- It can be used anonymously : no user account is required to trigger it;
- It can lead to information disclosure , and in some cases to privilege escalation, or even remote code execution (RCE ) .
It is this combination, no authentication required, potential impact up to RCE, which justifies the score of 20/25 given by Drupal, even though the official CVSS score published by CVE.org is 6.5.
The key point: only PostgreSQL sites are exposed to SQL injection
This is the most important element to remember, and the one that is most often misinterpreted in media reports.
The SQL injection vulnerability only affects Drupal sites using PostgreSQL as the database.
Drupal sites running on MySQL or MariaDB are not vulnerable to this SQL injection. This is due to differences in how the drivers handle quoting and parameter typing: the vulnerability exploits a behavior specific to the PostgreSQL driver of the Drupal abstraction layer.
It is this limited scope that led Drupal to classify the target as "Uncommon" in the details of the risk rating — while maintaining the Highly Critical severity for the sites actually concerned.
The security note specifies that ALL versions of Drupal since 8.9.0!
Drupal versions prior to 10.4 are no longer covered by security patches. If you are affected, you need to complete any upgrades as soon as possible or seek assistance to fix the issues.
The Symfony and Twig aspect: the devil is in the detail
This is where you need to be careful not to jump to conclusions. If you're using MySQL, you might be tempted to conclude that this release doesn't apply to you. That would be a mistake.
The Drupal releases for the supported branches (11.3, 11.2, 10.6, and 10.5) as part of security updates also include coordinated security updates for Symfony and Twig . These two projects, on May 20th, published a series of messages indicating the correction of 35 CVEs in Symfony and Twig. These updates were released a few hours before the Drupal updates, in coordination with the security teams.
These Symfony and Twig fixes apply to all Drupal sites, regardless of the database used.
Depending on your configuration and the contributed modules installed, your site may be exposed to one or more of these upstream vulnerabilities. The Drupal security team therefore explicitly recommends updating, whether you are using PostgreSQL or not. This is an important message to convey to IT departments and operations teams: the quick assumption "I'm using MySQL, so I'm not affected" is partially false.
One additional point to note: remember to check which user roles have the right to modify Twig templates (for example, via Views or modules that allow template manipulation). This is a secondary factor to audit as part of these fixes.
Affected versions and remediation plan
Affected versions and official fixes
The following supported branches have an official patch that should be applied immediately:
- Drupal 11.3.x — Update to the latest patch version
- Drupal 11.2.x — Update to the latest patch version
- Drupal 10.6.x — Update to the latest patch version
- Drupal 10.5.x — Update to the latest patch version
Best effort fixes for EOL branches
Given the severity of the issue, the Drupal team made the exceptional effort to release best-effort patches for branches that were officially at end of life:
- Drupal 11.1.x
- Drupal 10.4.x
- Drupal 9.5.x
- Drupal 8.9.x
If you are on one of these branches, this is an opportunity to apply the emergency patch, and above all, it is a strong signal that a migration path to a supported branch is becoming a priority.
Drupal 7: not applicable
Drupal 7 is not affected by this vulnerability. No action is required under CVE-2026-9082 on these sites. This obviously does not change the overall need to plan a migration from Drupal 7, which is no longer in community support as of January 2025.
Immediate Action Checklist
- Identify your stack : which database? Which version of Drupal? Which contributed modules that manipulate Twig templates?
- Apply the core patch corresponding to your branch.
- Audit the roles that have permissions to modify Twig templates or edit Views.
- Check recent access logs for abnormal requests; the window between announcement and patch was short but real.
- Re-test your pre-production environments before deployment.
A word on the Drupal community's handling of the incident
Beyond the patch itself, one thing deserves to be highlighted: the quality of the process . The Drupal security team has:
- A Public Service Announcement was published two days in advance to allow ops teams to block a deployment slot;
- Announced a specific release window (5:00 PM–9:00 PM UTC on May 20th);
- Coordinated disclosure with Symfony and Twig to avoid asynchronous publication of upstream advisories;
- Extended the fixes to officially EOL branches , using best effort.
This is exactly what we expect from a mature open source project, and that's also why we at Smile continue to recommend and support Drupal on sensitive projects: robustness is not only in the code, it is also in the incident response process.
In summary
- The vulnerability is real and severe , but its SQL injection scope is limited to PostgreSQL sites .
- Embedded Symfony and Twig updates affect all Drupal sites , regardless of the database.
- The EOL branches benefit from a best effort fix, take the opportunity to plan the migration.
- The Drupal ecosystem has, once again, demonstrated the quality of its security management.
If you would like an exposure audit of your Drupal site, validation of your remediation plan, or to discuss a migration strategy from an EOL branch, my team and I are available to assist you. You can contact us directly via our contact form .
