On May 20, 2026, Drupal disclosed CVE-2026-9082, a critical SQL injection vulnerability with a CVSS score of 9.8. Two days later, CISA added it to the Known Exploited Vulnerabilities catalog. This vulnerability affects only Drupal sites running PostgreSQL—installations using MySQL, MariaDB, or SQLite remain unaffected. Attackers can exploit it remotely without authentication.
This incident highlights a dangerous assumption: that database abstraction layers protect you from backend-specific vulnerabilities. They don't.
Timeline
May 20, 2026: Drupal Security Team discloses CVE-2026-9082 and releases patches.
May 22, 2026: CISA adds CVE-2026-9082 to the KEV catalog, confirming active exploitation.
The window between disclosure and confirmed exploitation was 48 hours or less. If your team runs Drupal on PostgreSQL and didn't patch within that window, assume compromise.
Which Controls Failed
Asset inventory blind spots: Organizations that tracked "Drupal instances" without recording the underlying database engine couldn't identify affected systems. Your CMDB needs to capture the full stack—application version, database type and version, web server, and OS. A generic "Drupal 10.x" entry tells you nothing about PostgreSQL exposure.
Database-agnostic testing: Security teams that tested SQL injection defenses against MySQL didn't catch PostgreSQL-specific attack vectors. The abstraction layer that promises portability also hides backend differences. If your test suite runs against one database engine, you're not testing your actual attack surface.
Patch deployment SLAs: A 48-hour exploitation window makes standard 30-day patch cycles irrelevant. Organizations with "critical patches within 7 days" policies were already breached before the policy kicked in. Your SLA needs to distinguish between "critical" and "critical with active exploitation."
Public exposure without WAF protection: Drupal sites accessible directly from the internet, without a web application firewall performing SQL injection detection, gave attackers a clean path. The vulnerability requires no authentication—any request to the application could carry the payload.
What Standards Require
PCI DSS v4.0.1 Requirement 6.3.1 mandates that you identify security vulnerabilities using reputable outside sources and assign a risk ranking to newly discovered vulnerabilities. The ranking must include whether the vulnerability affects your environment. A generic "Drupal vulnerability" assessment fails this requirement. You need: "CVE-2026-9082 affects our customer portal (PostgreSQL 14.2) but not our admin panel (MySQL 8.0)."
PCI DSS v4.0.1 Requirement 6.3.3 requires high-risk vulnerabilities to be addressed "based on the risk ranking defined in Requirement 6.3.1." For a CVSS 9.8 vulnerability with confirmed exploitation, "based on risk" means emergency patching, not your normal cycle.
NIST CSF v2.0 function PR.IP-12 (Govern > Risk Management Strategy) states: "Vulnerabilities are identified, validated, and a response is orchestrated." The response must account for exploitation speed. A vulnerability disclosed Monday and exploited Tuesday requires a response measured in hours, not days.
ISO/IEC 27001:2022 Control 8.8 (Management of technical vulnerabilities) requires you to obtain timely information about technical vulnerabilities and evaluate exposure. "Timely" is relative to attacker speed. When CISA adds a vulnerability to KEV within 48 hours, your evaluation cycle needs to match that tempo.
OWASP ASVS v4.0.3 Section 5.3.4 addresses parameterized queries and ORM usage, but it assumes the ORM is correctly implemented across all supported backends. This vulnerability shows that assumption breaks down. Your verification must include backend-specific injection testing.
Lessons and Action Items
Map your database backends today: Run this query against your asset inventory: "Show me every application instance, its database type, and version." If you can't answer that in under 10 minutes, your CMDB is inadequate. Add database engine and version as mandatory fields for every application record.
Build backend-specific test cases: If your application supports multiple database engines, your SQL injection test suite needs dialect-specific payloads. PostgreSQL supports different functions, operators, and syntax than MySQL. A test that passes against MySQL proves nothing about PostgreSQL security. Schedule quarterly reviews of your test coverage against each supported backend.
Implement emergency patching procedures: Define what triggers emergency patching (CVSS 9.0+ with confirmed exploitation is a good threshold) and document who can authorize production changes outside the normal change window. Your emergency procedure should target deployment within 24 hours of vendor patch availability. If that's impossible for some systems, those systems need compensating controls.
Deploy WAFs in detection mode immediately: Even if you're not ready to enable blocking, get a WAF deployed in front of public-facing applications and configure it to log SQL injection attempts. When the next CVE drops, you'll know within hours whether you're under attack. This gives you data to justify emergency patching to change control boards.
Require backend specification in vulnerability reports: When your vulnerability scanner or SBOM tool reports "Drupal vulnerable to CVE-2026-9082," that's insufficient. The report must state: "Drupal 10.2.1 on PostgreSQL 14.2 is vulnerable. Drupal 10.2.1 on MySQL 8.0 is not affected." Train your tooling or your analysts to include this context.
Test your emergency response tempo: Run a tabletop exercise: "A critical, actively exploited vulnerability affecting 30% of our web applications is disclosed at 5 PM Friday. Walk through the next 48 hours." Identify the bottlenecks—approval chains, testing requirements, deployment tooling. Fix them before you need them.
The CVE-2026-9082 incident proves that abstraction layers create blind spots. Your security controls must see through the abstraction to the actual technology stack. When attackers move in 48 hours, your detection, decision-making, and deployment must move faster.
