Drupal patches highly critical SQL injection (CVE-2026-9082) — exploited in the wild within 48h

Drupal shipped an emergency advisory for CVE-2026-9082 on May 18, then bumped the risk score four days later when active exploitation kicked in. The flaw is an unauthenticated SQL injection in Drupal core's database abstraction API, and it's scored 23/25 — Highly Critical on Drupal's own scale.

The catch — and the one bit of good news — is that only sites backed by PostgreSQL are exploitable. MySQL, MariaDB and SQLite installations are not vulnerable.

Affected versions

A long range of branches needs patching:

• >= 8.9.0 < 10.4.10
• >= 10.5.0 < 10.5.10
• >= 10.6.0 < 10.6.9
• >= 11.0.0 < 11.1.10
• >= 11.2.0 < 11.2.12
• >= 11.3.0 < 11.3.10

Fixed in 10.4.10, 10.5.10, 10.6.9, 11.1.10, 11.2.12, 11.3.10. Apply the patch matching your branch — Drupal does not back-port further than the branches above.

What the bug does

Drupal's database abstraction layer is supposed to sanitize values fed into queries. CVE-2026-9082 lets a crafted request reach the PostgreSQL EntityQuery condition handler with unsanitized array keys, which slip into the query string verbatim. From there, an unauthenticated attacker can read or modify anything the Drupal database user has access to — and on a typical setup, that's everything.

Drupal's advisory phrases it dryly: confidentiality impact is "all non-public data accessible," integrity impact is "all data modifiable or deletable." On many configurations, the flaw chains into RCE through COPY ... FROM PROGRAM if the PostgreSQL role is superuser — a far-too-common misconfiguration.

The vulnerability was reported by Michael Maturi of Google's Mandiant team.

Exploitation status

Drupal updated the advisory on May 22 to confirm exploit attempts in the wild. Within the first 48 hours, multiple vendors reported probing across thousands of sites in 65+ countries — automated mass-scanning, opportunistic rather than targeted.

What to do today

1. Patch. Same-day if your site uses PostgreSQL. Same-week even if it doesn't, because mistakes happen and a future regression could change that.
2. Confirm your DB backend. Look at settings.php for the driver — pgsql means you are exposed; mysql, mariadb or sqlite means you are not.
3. Audit your PostgreSQL role. If Drupal connects as a superuser, demote it. The principle of least privilege turns a bad SQLi into a contained one.
4. Hunt for indicators. Unexpected new admin users, modified entries in users_field_data, or new content nodes you can't account for. Check web server access logs for unusual query strings hitting /jsonapi/, /views/ajax, and form endpoints in the last week.
5. Plan rotation. Treat any compromised site as a credential-leak event — rotate keys, sessions, API tokens stored in or accessible from Drupal.

CISA had not yet added CVE-2026-9082 to the KEV catalog at press time, but given the exploitation telemetry it likely will within days.