What Happened
Drupal recently released emergency security updates for six supported versions to patch CVE-2026-9082, a vulnerability that allows anonymous users to execute remote code on sites using PostgreSQL databases. The flaw has a CVSS score of 6.5 and affects Drupal's core query builder. No authentication or special privileges are required—just an anonymous HTTP request to the right endpoint.
Patches were released for versions 11.3.10, 11.2.12, 11.1.10, 10.6.9, 10.5.10, and 10.4.10. In an unusual move, the Drupal Security Team also backported fixes to Drupal 8 and 9, despite these versions being past their end-of-life, due to the severity of the issue.
Timeline
- Day 0: The vulnerability is identified in the database abstraction layer affecting PostgreSQL implementations.
- Day 0+hours: Emergency patches are developed and tested against PostgreSQL 12, 13, 14, 15, and 16.
- Day 1: A security advisory is published, and updates are released for six supported versions. Backports for EOL versions 8 and 9 are made available.
- Day 1+4 hours: Proof-of-concept code appears in security research channels.
- Current state: Active exploitation has not been confirmed, but the risk of anonymous access and RCE makes timely patching critical.
Which Controls Failed or Were Missing
Input Validation at the Database Layer: The vulnerability arises from Drupal's query builder failing to sanitize user inputs before passing them to PostgreSQL, allowing SQL injection that can lead to code execution.
Database Privilege Separation: Many Drupal installations use database credentials with excessive permissions. If the application user has CREATE, EXECUTE, or filesystem access, a SQL injection vulnerability can escalate to RCE.
Patch Deployment Velocity: Organizations running Drupal 8 or 9 assumed security updates would cease. The emergency backport challenges this assumption, highlighting the need for monitoring and deployment pipelines for EOL software.
Anonymous User Surface Area: The vulnerability can be exploited by unauthenticated users, exposing every public-facing form, search box, or API endpoint that interacts with the database. If anonymous access isn't restricted, you're at risk.
What the Relevant Standards Require
PCI DSS v4.0.1 Requirement 6.3.2 mandates maintaining an inventory of software components, including CMS platforms, with their security status. A CVSS 6.5 RCE exploitable by anonymous users is high-risk.
Requirement 6.3.3 requires installing security patches for critical vulnerabilities within one month. For internet-exposed systems, you need documented evidence of patch deployment or compensating controls if delayed.
ISO/IEC 27001:2022 Control 8.8 requires obtaining timely information about vulnerabilities, evaluating exposure, and taking appropriate measures. Emergency patches for EOL versions signal immediate action is needed.
NIST 800-53 Rev 5 SI-2 requires installing security-relevant updates within defined time periods. For internet-facing applications with RCE vulnerabilities, this should be days, not weeks.
Most teams lack a process for handling EOL software when vendors break their own policies. If your change control process requires vendor support status, it becomes a barrier to emergency patching.
Lessons and Action Items for Your Team
Audit Your Database Permissions Today: Check your Drupal database permissions. If you see SUPERUSER, CREATEROLE, or CREATEDB, reduce privileges to only SELECT, INSERT, UPDATE, and DELETE on application tables. Document this change for your next audit.
Map Your Anonymous Attack Surface: Identify every Drupal endpoint accessible without authentication. Trace each one to see if it constructs database queries using user input. If unpatched, disable or restrict these endpoints.
Fix Your EOL Software Process: Update your software lifecycle policy to define "end of life" as "end of vendor's commitment to support." Your change control board should have the authority to approve emergency patches for EOL systems.
Redefine Your Patching SLA for CMS Platforms: Set a 72-hour target for critical CMS patches. Document and approve this change to ensure a faster response than the typical 30-day window.
Test Your Patch Deployment Pipeline: Ensure you can deploy a Drupal update outside business hours, have a rollback plan, and can patch without site downtime. Address any gaps before the next vulnerability arises.
Verify Your PostgreSQL Version: Drupal's patches were tested against PostgreSQL 12 through 16. If you're running PostgreSQL 11 or earlier, schedule an upgrade to avoid future vulnerabilities.
The Drupal Security Team's decision to release patches for EOL versions provides a critical window for teams with legacy deployments. Use this time wisely.
