CVE-2026-9082: Drupal Core SQL Injection Detection with Sn1per

CVE-2026-9082 is a highly critical, unauthenticated SQL injection in Drupal
core’s database abstraction layer. It affects sites running on PostgreSQL, it
is in the CISA Known Exploited Vulnerabilities catalog, and it is being exploited in the wild.
This post explains what the flaw is, how to tell if you are exposed without attacking your own
site, and how to find every affected Drupal host across your attack surface with Sn1per.

CVE-2026-9082 at a glance

What is CVE-2026-9082?

Drupal core provides a database abstraction API so module code can build queries without
writing raw SQL. CVE-2026-9082 is a flaw in how that layer neutralizes special elements when
it builds entity queries against a PostgreSQL backend. A specially crafted
request reaches the vulnerable code path and lets an anonymous attacker inject SQL into the
generated query.

Two unauthenticated routes into the vulnerable code have been described publicly: the
JSON:API filter syntax (for example the query parameters on an endpoint such as
/jsonapi/node/article) and a JSON login endpoint. Because JSON:API is on by
default in many modern Drupal builds and is reachable without a session, the practical exposure
for an internet-facing PostgreSQL Drupal site is high.

The precondition matters. The bug lives in PostgreSQL-specific query handling, so a Drupal
site on MySQL or MariaDB is not exploitable through this issue. That does not make the update
optional – it means PostgreSQL sites should treat this as an emergency and everyone else should
still patch on the normal security cadence.

Affected and fixed versions

Drupal fixed CVE-2026-9082 across every supported branch. Update to the fixed release for
your branch. Sites on unsupported branches (below the ranges shown) receive no fix and must
move to a supported release.

Drupal also published best-effort manual patches for the end-of-life 8.9 and 9.5 branches.
Confirm the installed version on the host with drush status or
composer show drupal/core rather than trusting an advertised version.

How the vulnerability works (detection-only)

We are deliberately not publishing a working injection string. The mechanics that matter for
defenders are:

• The entry point is an anonymous request to a JSON:API resource or the JSON login
  endpoint. No credentials are required.
• The crafted input is carried in query parameters that flow into an entity query. On
  PostgreSQL, the abstraction layer fails to neutralize a special element, so attacker input
  changes the structure of the executed SQL.
• Successful injection yields read access to the database and, depending on database
  privileges and site configuration, can be chained further.

Defenders have reported scanner traffic carrying markers such as
nuclei_sa_core_2026_004 against /jsonapi/node/article, which is a
useful thing to grep your own access logs for. If you see anonymous JSON:API requests with
unusual filter parameters that predate your patch, treat the host as potentially probed and
review database and application logs.

Quick manual checks

Before scaling this up, three checks tell you most of what you need on a single host:

1. Is it Drupal, and what major version? Look for
   <meta name="Generator" content="Drupal 11 ..."> in the homepage source or
   an X-Generator: Drupal response header.
2. What patch level? Request /core/CHANGELOG.txt. Its first
   line names the exact release, for example Drupal 11.3.10, 2026-05-20. Compare it
   to the fixed-version table above. If the file has been removed, confirm on-host with
   drush status.
3. Is JSON:API exposed? A GET to /jsonapi that returns a JSON
   document indicates the module is enabled and anonymously reachable, which is the path most
   exploitation is using.

The Nuclei template

ProjectDiscovery ships an official template for this CVE, so if you run current
nuclei-templates you already have it:

# Confirm you have it, then run it against a host or a list
nuclei -id CVE-2026-9082 -u https://drupal.example.com
nuclei -id CVE-2026-9082 -l drupal-hosts.txt

The template is tagged drupal,sqli,postgresql,kev and is classified critical
(CWE-89). It works by exercising JSON:API content bundles such as article and
page to confirm the anonymous injection path, and it is marked verified. Keep your
templates current so KEV-tagged detections like this one are present:

nuclei -update-templates

If /core/CHANGELOG.txt is your only signal on a hardened host, a version
fingerprint is a reasonable fallback: any PostgreSQL Drupal below the fixed release for its
branch should be treated as exposed until proven patched.

Find every affected Drupal host with Sn1per

Running one template against one URL is easy. The real problem is knowing every Drupal
instance you own – staging copies, forgotten subdomains, an acquisition’s marketing site – and
running the check across all of them continuously. That is what
Sn1per is built for.

Sn1per handles the reconnaissance
that finds those hosts, fingerprints the technology on each one, and runs curated Nuclei
templates (including KEV-tagged CVEs like this one) as part of its
external attack surface management
pipeline. A typical workflow:

# Discover the surface, then run web detections into a persistent workspace
sniper -t example.com -m recon -w acme
sniper -t example.com -m web   -w acme

# Or target a single known Drupal host
sniper -t https://drupal.example.com -m web -w acme

Findings land in the workspace with the affected URL and the matched evidence, so you can
triage the CVE-2026-9082 hits, confirm which are PostgreSQL-backed, and prioritize patching.
Because Sn1per re-runs on a schedule, a host that gets rolled back to a vulnerable image, or a
new subdomain that appears next quarter, is caught the next time the workspace scans rather
than never.

Which edition fits

Why on-premise matters here

Drupal SQL injection findings are sensitive: they map your unpatched, internet-facing,
database-backed systems. Sn1per runs entirely inside your own perimeter, so that inventory of
exposed hosts never leaves your control. For teams that will not send attack-surface data to a
third-party cloud scanner, a self-hosted platform is the difference between running the check
and not running it at all.

Remediation

1. Patch now. Update Drupal core to the fixed release for your branch:
   10.4.10, 10.5.10, 10.6.9, 11.1.10, 11.2.12 or 11.3.10 (or later). This is the only complete
   fix.
2. Prioritize PostgreSQL sites. They are the exploitable population. If you
   cannot patch immediately, put a WAF rule in front of JSON:API and the JSON login endpoint as
   a temporary control, understanding that filtering is not a substitute for the update.
3. Hunt for prior exploitation. This CVE is actively exploited, so patching
   is not enough on its own. Review access logs for anomalous anonymous JSON:API requests, check
   for unexpected database queries or new users, and rotate secrets if you find evidence of
   read access to the database.
4. Verify, do not assume. Confirm the running version on each host after
   patching, and re-scan to prove the finding is cleared.

Frequently asked questions

Is CVE-2026-9082 being exploited in the wild?

Yes. It is in the CISA Known Exploited Vulnerabilities catalog and public reporting
describes thousands of exploitation attempts against Drupal sites. Treat internet-facing
PostgreSQL Drupal instances as an emergency.

My Drupal site uses MySQL. Am I affected?

The exploitable flaw is in PostgreSQL-specific query handling, so MySQL and MariaDB sites are
not exploitable through this issue. You should still update core to the fixed release on your
normal security cadence.

How do I check my Drupal version without attacking the site?

Request /core/CHANGELOG.txt and read the first line, or run
drush status / composer show drupal/core on the host. Compare against
the fixed-version table above. The generator meta tag only tells you the major version, which
is not enough to decide patch state.

Does Sn1per detect CVE-2026-9082?

Yes. Sn1per runs curated Nuclei templates as part of its scan pipeline, and the official
CVE-2026-9082 template is KEV-tagged and included in current template sets. Sn1per adds the
discovery and continuous-scanning layer so you find every Drupal host you own, not just the one
URL you already knew about.

Is scanning for this safe to run against production?

A version-fingerprint check against /core/CHANGELOG.txt is entirely
non-destructive. The official CVE template exercises the JSON:API detection path; run it in a
maintenance window if you are cautious, and never run a weaponized injection string against a
system you do not own.