The Drupal SQL injection flaw: Why a "Medium" CVSS Score Misses the Real Threat
Security advisories often misrepresent the actual risk. We are currently observing active exploitation of a recently disclosed critical Drupal SQL injection flaw. While Drupal rates this "highly critical", a common CVSS v3 assessment might place it at a "medium" 6.5. This discrepancy often leads to confusion, making it challenging for organizations to accurately prioritize patching efforts. Just days post-patch release, significant exploitation attempts are underway, underscoring its status as an active, rather than theoretical, threat.
How a Database Abstraction Flaw Became an Immediate Problem
This vulnerability resides within Drupal's database abstraction API, a critical layer typically responsible for sanitizing inputs and preventing malicious queries. Google/Mandiant researcher Michael Maturi discovered that this API could be manipulated to permit arbitrary Drupal SQL injection. This specific Drupal SQL injection vulnerability highlights the dangers of insufficient input sanitization.
Crucially, this vulnerability only affects sites using PostgreSQL databases. Drupal sites running MySQL or other database systems are not directly susceptible to the SQLi itself. However, patching remains essential for all Drupal deployments.
The attack unfolds directly: an unauthenticated attacker sends a specially crafted request to a vulnerable Drupal site. The database abstraction layer, failing to properly sanitize input for PostgreSQL, executes the attacker's malicious SQL code. This classic Drupal SQL injection, leveraging techniques such as T1190: Exploit Public-Facing Application, is particularly severe due to its unauthenticated nature and presence in a core API.
The Impact: Beyond Information Disclosure
While information disclosure—the extraction of sensitive data directly from your PostgreSQL database—is a primary risk, the potential impact extends further. This Drupal SQL injection can compromise sensitive user data and system configurations.
Privilege Escalation: Depending on database configuration and application privileges, an attacker could elevate their access within the database, potentially gaining control over the Drupal application itself.
Remote Code Execution (RCE): In specific configurations, a successful Drupal SQL injection can lead to RCE. This is the most severe outcome, allowing an attacker to execute arbitrary commands on the server hosting the Drupal site.
Security researchers, specifically Imperva, have documented over 15,000 exploitation attempts targeting nearly 6,000 sites across 65 countries. Almost half of these attacks focus on high-value targets like gaming and financial services platforms.
Currently, most activity involves reconnaissance and validation, with attackers identifying vulnerable PostgreSQL-backed Drupal configurations. This probing will quickly transition to data extraction or privilege escalation once targets are confirmed. The limited use of PostgreSQL by less than 5% of Drupal sites does reduce the overall attack surface. However, for those sites, the risk is exceptionally high.
Why the Severity Score Matters (and Why Drupal's Is Right)
This divergence in severity scores presents a challenge for administrators. Drupal rates this SQL injection vulnerability as "highly critical", while a common CVSS v3 assessment might assign a "medium" 6.5. This disparity causes confusion, as evidenced by discussions in security communities. Administrators often grapple with which assessment should guide their response.
Drupal's internal rating is the more accurate measure for your Drupal deployments. NIST's CVSS score is a general, standardized metric, designed for broad applicability. Drupal's internal score, however, is tailored to the specific context of its platform and typical deployments.
When Drupal designates a vulnerability as "highly critical," they factor in ease of exploitation (unauthenticated), potential impact (RCE, privilege escalation), and its location within a core component. Their internal risk score, recently updated from 20 to 23 (out of 25) specifically due to detected exploitation attempts, and their assessment of rapid exploitation aligns with current observations.
Historical context reinforces this. Drupal has not seen a highly critical Drupal SQL injection vulnerability of this specific nature patched in recent years, and there have been no reports of new Drupal vulnerabilities exploited in the wild since 2019. Prior to that, "Drupalgeddon" and "Drupalgeddon2" caused widespread disruption. This is not a minor bug; it represents a return to a level of severity not seen in Drupal for a considerable period.
Immediate Actions for Drupal Administrators
Immediate action is required: upgrade your Drupal installation.
For Drupal 10.4.x: Upgrade to 10.4.10.
For Drupal 10.5.x: Upgrade to 10.5.10.
For Drupal 10.6.x: Upgrade to 10.6.9.
For Drupal 11.0.x / 11.1.x: Upgrade to 11.1.10.
For Drupal 11.2.x: Upgrade to 11.2.12.
For Drupal 11.3.x: Upgrade to 11.3.10.
Even if your site does not use PostgreSQL, an update is still necessary. These patches include fixes for upstream dependencies like Symfony and Twig, which may carry their own security implications.
If you are running Drupal 8 or 9, your situation is significantly riskier. These versions are End-of-Life (EOL) and receive only "best-effort" patches, if any. They contain other known vulnerabilities, making continued use inherently risky. This Drupal SQL injection vulnerability underscores the critical need to accelerate migration off EOL platforms.
Key Takeaways
This is not a "medium" severity issue for any organization operating a PostgreSQL-backed Drupal site. It is a highly critical, actively exploited Drupal SQL injection vulnerability capable of leading to unauthenticated remote code execution. Drupal's internal assessment is accurate and should inform your immediate response. Patching is not merely optional; it is a fundamental requirement for maintaining robust security.
