Drupal released security updates for CVE-2026-9082, tracked by the project as SA-CORE-2026-004, after confirming a highly critical SQL injection flaw in Drupal core’s database abstraction layer. The dangerous part is the exposure model: a vulnerable public site using PostgreSQL can be reached by an anonymous user, so the issue does not depend on stolen admin credentials.
The flaw affects Drupal core versions from 8.9.0 before 10.4.10, 10.5.0 before 10.5.10, 10.6.0 before 10.6.9, 11.0.0 before 11.1.10, 11.2.0 before 11.2.12, and 11.3.0 before 11.3.10 [2]. Drupal’s advisory says the SQL injection path applies to sites using PostgreSQL, while coordinated Symfony and Twig dependency updates included in the same releases matter for all supported branches [1].
Why this Drupal flaw matters
SQL injection against a public CMS can become a data exposure event before anyone notices visible defacement. Depending on the site’s configuration and enabled modules, Drupal warns that impact may extend beyond data access to privilege escalation or remote code execution. That makes this a patch-now issue for exposed production sites, not a routine maintenance item.
The PostgreSQL detail is important. Admins should verify the actual production database driver, not only what a staging or development copy uses. Many organizations have multiple Drupal environments, and the one with public traffic may not match the one developers test locally.
Fixed versions
- Drupal 11.3.10
- Drupal 11.2.12
- Drupal 11.1.10
- Drupal 10.6.9
- Drupal 10.5.10
- Drupal 10.4.10
Drupal 8 and Drupal 9 are already end-of-life. If an unsupported branch is still in production, treat the patch as a temporary containment step and plan a supported upgrade path.
What to check after patching
- Confirm the running site, not only the repository, reports a fixed Drupal core version.
- Verify whether the production database is PostgreSQL.
- Review web server logs for unusual query-heavy requests and unexpected 500 errors.
- Check for new admin-level users, changed roles, modified content, or suspicious file uploads.
- Review database access logs if available, especially around public traffic spikes.
This same exposure logic is why we track CMS flaws such as Avada Builder SQLi risk and broader hosting control panel vulnerabilities: the first visible symptom is often not the first compromise.
