CVE-2026-9082

What it actually does

This is an unauthenticated, network-exploitable SQL injection vulnerability in Drupal core caused by improper neutralization of SQL metacharacters before data is used in a database query. An attacker can submit crafted input to a vulnerable Drupal endpoint and alter the intended SQL query. Based on the provided CVSS vector, likely outcomes include unauthorized reading of limited database content and limited modification of data; availability impact is not indicated. Because Drupal stores application content, user records, configuration, sessions, and other security-sensitive data in the database, even a partial SQL injection can expose or tamper with important application data depending on the vulnerable code path and database permissions.

Why it matters to the business

A vulnerable Drupal site may allow an internet-based attacker to read or change website data without logging in, which can lead to content tampering, account or personal-data exposure, compliance impact, and loss of trust in public-facing web properties. The risk is elevated because exploitation is reported as active in the wild, EPSS is very high at 0.88319, and the issue is listed in CISA KEV with a remediation due date of 2026-05-27. Organizations running affected Drupal core versions should treat remediation as urgent even though the CVSS score is moderate.

How an attack unfolds

An attacker first identifies an internet-facing Drupal instance and determines whether it is running an affected core version, typically through exposed Drupal metadata, asset fingerprints, response behavior, or version-specific paths. The attacker then sends specially crafted HTTP requests containing SQL control characters or expressions to the vulnerable Drupal functionality. If the input reaches the affected query construction path without proper parameterization or escaping, the database interprets part of the attacker-controlled input as SQL rather than data. The attacker can then test for injection by observing response differences, database errors, timing behavior, or content changes. Once confirmed, the attacker may enumerate accessible tables, extract selected data, alter website content or user-related records within the limits of the vulnerable query and database account privileges, and attempt to chain the issue with other weaknesses for broader compromise. Active exploitation and KEV status indicate that defenders should assume public exploit knowledge and opportunistic scanning are likely.

How to fix it

Upgrade Drupal core to a fixed release in the appropriate supported branch. The affected ranges are Drupal core 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. Minimum fixed versions are therefore 10.4.10, 10.5.10, 10.6.9, 11.1.10, 11.2.12, and 11.3.10 depending on the deployed branch; where possible, move to the latest supported Drupal core release rather than only the minimum patched version. If immediate upgrade is not possible, reduce exposure by restricting access to affected sites, placing stricter WAF rules in front of Drupal, blocking obvious SQL injection payloads, disabling unnecessary public endpoints or modules that expose user-controlled query parameters, and ensuring the Drupal database user has the least privileges needed for the application. Mitigations should be treated as temporary; patching Drupal core is the durable fix.

How to confirm the fix worked

Confirm the installed Drupal core version is at or above the fixed version for its branch by checking Composer metadata, Drupal administrative reports, package manifests, deployment artifacts, or the output of Drupal maintenance tooling. Verify that no production instance remains in the affected ranges: 8.9.0 through versions before 10.4.10, 10.5.x before 10.5.10, 10.6.x before 10.6.9, 11.0.x before 11.1.10, 11.2.x before 11.2.12, or 11.3.x before 11.3.10. After upgrading, run regression testing against business-critical Drupal functionality and confirm that security update notices no longer flag the issue. For exposure validation, review externally reachable Drupal sites, reverse proxies, CDN origins, containers, and build images to ensure no outdated Drupal core copy is still deployed. If vulnerability scanning is used, prefer authenticated checks or version-based checks tied to the exact Drupal core branch, and avoid destructive SQL injection probes on production systems.

Typical attack path

1. Scan for internet-facing Drupal sites and fingerprint core version or vulnerable behavior.
2. Send crafted HTTP requests to Drupal endpoints that may pass attacker-controlled input into SQL queries.
3. Confirm injection using response differences, SQL error messages, boolean conditions, timing payloads, or unexpected content changes.
4. Enumerate accessible database structure or data exposed through the injectable query context.
5. Read sensitive records or modify application data where database permissions and query context allow.
6. Attempt follow-on actions such as content defacement, account manipulation, credential/session abuse, or chaining with additional vulnerabilities.

How to detect it

Investigate for prior exploitation using layered log sources: web server access logs, reverse proxy logs, CDN logs, WAF events, Drupal application logs, database query logs where available, authentication and account-management logs, and file integrity or content-change records. Focus on the period from 2026-05-20 onward, with additional lookback if suspicious activity predates publication. Search HTTP request paths, query strings, POST bodies where logged, user agents, and WAF-normalized parameters for SQL injection syntax such as UNION SELECT, stacked queries, boolean conditions, comments, database metadata table names, and timing functions. Correlate suspicious requests with unusual Drupal outcomes: SQL errors, 500 responses, unusually large responses, repeated parameter fuzzing, content edits not tied to legitimate editors, unexpected user role changes, new privileged users, anomalous session activity, or database reads from unusual sources. If database audit logging exists, review for unexpected SELECT, UPDATE, INSERT, or DELETE operations against Drupal content, user, role, session, or configuration tables around suspicious web requests. Treat generic scanner traffic differently from successful exploitation by looking for response-size changes, status-code changes, follow-on authenticated activity, persistent data changes, or repeated payload refinement from the same source.

• UNION SELECT
• UNION ALL SELECT
• information_schema
• pg_catalog
• sqlite_master
• SLEEP(
• BENCHMARK(
• WAITFOR DELAY
• DBMS_PIPE.RECEIVE_MESSAGE
• OR 1=1
• OR '1'='1
• AND 1=1
• AND 1=2
• --
• /*
• */
• %27%20OR%20%271%27%3D%271
• %22%20OR%20%221%22%3D%221
• %20UNION%20SELECT%20
• %2F%2A
• SQL syntax
• You have an error in your SQL syntax
• PDOException
• SQLSTATE[
• DatabaseExceptionWrapper
• Drupal\\Core\\Database\\DatabaseExceptionWrapper
• drupal.org/project/drupal
• /core/CHANGELOG.txt
• /core/lib/Drupal/Core/Database/

What your security team should do

• Prioritize patching immediately because the vulnerability is in CISA KEV, is reported as actively exploited, and has a high EPSS probability.
• Inventory all Drupal core deployments, including public sites, staging sites exposed to the internet, containers, legacy installations, and downstream packaged distributions.
• Upgrade each affected Drupal branch to at least its fixed version, or preferably to the latest supported Drupal core release.
• If patching cannot be completed immediately, apply temporary WAF controls for SQL injection patterns and restrict access to non-public Drupal environments.
• Review web, WAF, reverse proxy, CDN, Drupal, and database logs for exploitation attempts since at least the publication date, 2026-05-20, and preferably earlier if logging retention allows.
• Hunt for unexpected database reads, content changes, user/account modifications, new administrator accounts, altered roles, and suspicious session activity following SQL injection attempts.
• Ensure the Drupal database account uses least privilege and cannot perform unnecessary administrative database operations.
• After remediation, rescan externally exposed Drupal assets and verify no affected core versions remain.
• Because the KEV due date was 2026-05-27, treat any still-vulnerable deployment as overdue and escalate through emergency change management.