Drupal SQL Injection: When Risk Scores Collide

What Happened

Drupal disclosed CVE-2026-9082, a SQL injection vulnerability in its database abstraction API that allows unauthorized database access and potential remote code execution. The flaw affects multiple Drupal versions and is now under active exploitation.

The disclosure created immediate confusion: Drupal assigned the vulnerability an internal severity score of 23 out of 25 (highly critical), while NIST rated it 6.5 on CVSS v3 (medium severity). This discrepancy left security teams with conflicting signals during active exploitation.

Timeline

• Disclosure: Drupal Security Advisory released, marking vulnerability as highly critical (23/25 internal score).
• NIST Assessment: National Vulnerability Database published CVSS v3 score of 6.5 (medium severity).
• Active Exploitation: Reports confirmed attackers exploiting the SQL injection flaw in the wild.
• End-of-Life Notice: Drupal clarified that versions 8 and 9 would not receive patches, as both reached end-of-life status.

Which Controls Failed or Were Missing

Input Validation at the API Layer: The database abstraction API failed to properly sanitize SQL queries, allowing injection attacks through user-supplied data. This reflects a failure in secure coding practices at the framework level.

Vulnerability Disclosure Coordination: The gap between Drupal's internal assessment and NIST's CVSS score suggests incomplete information sharing during the disclosure process. NIST may not have had access to Drupal's context about exploitability and attack surface when calculating the base score.

Lifecycle Management: Organizations running Drupal 8 and 9 had no patch path available. This is a control failure by the organizations that continued running end-of-life software without a migration plan.

Compensating Controls: The active exploitation indicates that organizations lacked defense-in-depth measures. A SQL injection vulnerability should encounter multiple barriers: web application firewalls, database permission restrictions, network segmentation, and anomaly detection.

What the Relevant Standard Requires

PCI DSS v4.0.1 Requirement 6.2.2: "Bespoke and custom software are reviewed prior to being released to production... to identify and correct potential coding vulnerabilities."

SQL injection ranks #3 on the OWASP Top 10 2021. If you process payment card data through a Drupal instance, this vulnerability creates an immediate PCI DSS compliance gap. Your QSA will ask: How did injection flaws reach production in your framework layer?

OWASP ASVS v4.0.3 Section 5.3.4: "Verify that the application uses query parameterization or other mechanisms to prevent SQL injection attacks."

The database abstraction API should have enforced parameterized queries by design. When your framework fails this control, you inherit the vulnerability across every application built on it.

NIST 800-53 Rev 5 SI-2 (Flaw Remediation): "Organizations identify, report, and correct system flaws... [and] install security-relevant software and firmware updates within the time period specified in the organizational assessment of risk."

Here's where the scoring discrepancy matters. SI-2 requires you to define remediation timelines based on your risk assessment. But which score do you use? Drupal's 23/25 suggests emergency patching. NIST's 6.5 suggests standard maintenance windows.

ISO/IEC 27001:2022 Annex A.8.8 (Management of Technical Vulnerabilities): "Information about technical vulnerabilities of information systems in use shall be obtained, the organization's exposure to such vulnerabilities evaluated and appropriate measures taken."

The standard requires you to evaluate exposure—not just accept a vendor score. You need context: Is the vulnerable code path reachable from your application? Do you have compensating controls? Are you exposed to the internet?

Lessons and Action Items for Your Team

Build a Scoring Triage Process: When vendor and NVD scores conflict, you need a decision framework:

1. Check CVSS subscores. A 6.5 base score can mask a 9.8 exploitability subscore if NIST assumed mitigating factors your environment lacks.
2. Verify the vendor's scoring rationale. Drupal's 23/25 likely factored in confirmed exploitation and ease of attack—context NIST may not have had.
3. Default to the higher score during active exploitation. You can debate severity later; patch first.

Map Your Framework Dependencies: If you run Drupal, Wordpress, or any CMS, document which core components your applications depend on. When a database API vulnerability drops, you need to know within one hour which production systems are affected. Build this map now: application → framework version → vulnerable component → data classification.

Set Lifecycle Cutoffs: The Drupal 8/9 end-of-life created an unpatchable vulnerability for organizations without migration plans. Your security policy needs hard dates:

• 90 days before vendor EoL: freeze new deployments on the platform
• 30 days before vendor EoL: complete migration or implement compensating controls
• Vendor EoL date: remove from production or accept the risk in writing

Test Your Compensating Controls: SQL injection should not be a single point of failure. Validate that you have:

• Database accounts with minimum necessary permissions (no DROP, CREATE, or GRANT unless required)
• Network segmentation preventing lateral movement from web tier to other systems
• WAF rules detecting common injection patterns (with logging to your SIEM)
• Anomaly detection on database query patterns

Run a tabletop exercise: "CVE drops on Friday at 4 PM. Vendor says critical. NIST says medium. Patch won't be ready until Monday. What do you do?" If your team doesn't have a documented answer, you'll improvise under pressure—and that's when mistakes happen.

Challenge the CVSS Score: NIST's base score assumes a generic environment. Your environment isn't generic. Calculate your own temporal and environmental scores using the CVSS calculator. A 6.5 base score becomes 8.9 when you factor in confirmed exploitation (temporal) and lack of compensating controls (environmental).

The Drupal incident exposes a gap in how we operationalize vulnerability management. Scores are inputs to your risk decision—not the decision itself. Build the process now, before the next 23-vs-6.5 debate happens during an active incident.