CVE-2026-9082: SQL Injection in Drupal Core Exploited in the Wild

Threat Intel
, , , ,
1

Last Updated: 2026-05-27T17:47:38Z

What’s Happening

CVSSv3: 9.8

CVE-2026-9082 is a critical SQL injection vulnerability in Drupal Core’s database abstraction API, specifically affecting the PostgreSQL EntityQuery condition handler. The vulnerability was disclosed by Drupal on 2026-05-20T07:00:00Z (advisory SA-CORE-2026-004) and added to CISA’s Known Exploited Vulnerabilities (KEV) catalog on 2026-05-22T07:00:00Z.

Affected Versions:

Branch Vulnerable Range
8.x 8.9.0 – 10.4.10 (excluding)
10.5.x 10.5.0 – 10.5.10 (excluding)
10.6.x 10.6.0 – 10.6.9 (excluding)
11.0.x 11.0.0 – 11.1.10 (excluding)
11.2.x 11.2.0 – 11.2.12 (excluding)
11.3.x 11.3.0 – 11.3.10 (excluding)

Technical Root Cause: The vulnerability stems from improper neutralization of attacker-controlled input in JSON: API filter parameter keys (not just values). PHP’s parser allows attackers to control array keys in query strings, which bypass sanitization logic and reach the PostgreSQL backend as arbitrary SQL. Common trigger points include the JSON:API core module, Views exposed filters, and Entity autocomplete endpoints.

Potential Impact: Information disclosure, privilege escalation, and potentially remote code execution depending on site configuration.

Actions

Upgrade to the following fixed versions as soon as possible:

  • 11.3.10
  • 11.2.12
  • 11.1.10
  • 10.6.9
  • 10.5.10
  • 10.4.10

EOL Branches (Drupal 8.9.x and 9.5.x):

Drupal has published best-effort manual patches for these unsupported branches. Note that these releases may still contain other previously disclosed security issues.

If Patching Isn’t Possible:

  1. Inventory all Drupal installations and verify backend database type (PostgreSQL vs. MySQL/MariaDB)
  2. Restrict access to /jsonapi/ endpoints — review if internet exposure is necessary
  3. Deploy WAF rules — Akamai, CrowdSec, and other WAF providers have released detection rules
  4. Monitor logs for suspicious activity on database-driven endpoints, especially crafted filter[...] parameters containing operators like ||, backticks, or time-delay expressions
  5. Prioritize public-facing sites accepting anonymous traffic

Hunting

Public exploits/tests reliably use the [operator]=IN pattern in reconnaissance to identify the vulnerability, and JSON patterns such as {"name":{"0":"x","0||1/(SELECT CASE WHEN (1=1) in POST requests to /user/login?format=json.

Notes

Drupal 7 is not affected because it does not include the JSON:API module.

Non-PostgreSQL sites should still update. While the SQLI vector is PostgreSQL-specific, the security release includes bundled Symfony and Twig fixes that apply to all deployments.

2

On the 21th of May Searchlight Cyber published a same-day technical write-up of the vulnerability. Source: Keys to the Kingdom: Anonymous SQL Injection in Drupal Core (CVE-2026-9082) › Searchlight Cyber

On the 22th of May, Defused publicly posted that they observed exploitation attempts at their honeypot. Source: https://x.com/DefusedCyber/status/2057868217507275244

Imperva mentioned exploitation attempts on the 21th of May. This corresponds to the publication date of the same-day technical write-up and is one day earlier than the currently reported ‘first observed exploitation date’. Source: https://www.imperva.com/blog/imperva-customers-protected-against-cve-2026-9082-in-drupal-core/

There are several public exploit scripts around with a number of targeted URL’s such as /jsonapi/node/article, /jsonapi/node/page and /user/login?_format=json. The login endpoint is targeted with SQL payloads such as SELECT CASE WHEN (1=1) THEN 0 END. Source: nuclei-templates/http/cves/2026/CVE-2026-9082.yaml at main · projectdiscovery/nuclei-templates · GitHub

Defused publicly only references the `/jsonapi/node` endpoint, while Impreva also mentions the jsonapi endpoint. Impreva also notices time-based SQL injections using pg_sleep which is notably absent in many public exploit scripts.

Maybe this should move to the threat intel category now that this is actively exploited?

3

Thank you for the additional links!

Our current internal policy is to move topics to Threat Intel once there is intelligence to hunt on, i.e. indicators of compromise/attack. Patching by itself is not “intelligence activity,” per se. It’s a debatable distinction, but one that has been useful so far. Once we see what attackers are doing with this, and who’s doing it, we’ll move the topic.

1 Like
4

I can only reference public information, but those URL’s and SQL statements are quite distinctive and can be used as indicators. The URL’s can even be combined with the vulnerable HTTP response codes 400/500, as this is how the exploit script determines if a site is vulnerable.

5

Fair enough! I will add those details to the top post and switch it.

1 Like