CVE-2026-9082: Testing Drupal’s Critical PostgreSQL SQL Injection

Greetings, fellow hackers! I'm Sandy, an Information Security Consultant and bug-bounty hunter. In this write-up, I want to share what I learned while testing CVE-2026–9082 in a controlled Drupal lab.

Some vulnerabilities begin with a complicated exploit chain. This one begins with something much smaller: an array key becoming part of a database placeholder name.

That detail caught my attention because this is not the usual SQL injection caused by a developer directly joining user input into a query. The problem sits deeper, inside Drupal Core's PostgreSQL query handling. An anonymous request can influence the way a placeholder name is built, and that small implementation detail can open the door to database access.

Drupal disclosed the issue on May 20, 2026. The GitHub Advisory Database scores it at 9.8, and CISA later placed it in the Known Exploited Vulnerabilities catalog. In simple terms: if a Drupal site uses PostgreSQL and has not been patched, this deserves immediate attention.

CVE-2026–9082 : Key Details

Where the vulnerability lives

Drupal uses a database abstraction layer so the same application code can work with different database engines. Normally, that layer also helps keep user input away from raw SQL syntax.

Here, the problem appears in the PostgreSQL-specific Entity Query condition handler. A user-controlled PHP array key can become part of a named SQL placeholder. That distinction matters. A prepared statement can safely bind a value, but it cannot protect query structure that was already built from untrusted input.

Following the input to the query

I found the easiest way to understand the bug was to follow the input from the HTTP request to the final query:

That was the important takeaway for me: prepared statements are not magic. Values may be bound safely while a placeholder name, identifier, or another structural part of the query is still unsafe.

Why I consider this bug dangerous

· Anonymous attack surface: a malicious user may not need a Drupal account.

· Remote reachability: exploitation can be attempted over HTTP against an exposed site.

· No victim interaction: no document opening or approval prompt is required.

· Sensitive database access: user records, password hashes, configuration data, private content, and business information may be exposed.

· Escalation potential: database write access can enable account takeover or persistent application changes; some configurations may permit broader compromise.

· Confirmed operational risk: CISA added the CVE to its Known Exploited Vulnerabilities catalog.

Affected and fixed Drupal versions

The official Drupal advisory identifies the following vulnerable ranges. The SQL injection path specifically affects sites using PostgreSQL.

Drupal 8, Drupal 9, and several listed branches are end-of-life. Emergency patches can reduce immediate exposure, but organizations should migrate to a supported release rather than treating an exceptional patch as a long-term solution.

Lab validation: from a small signal to real impact

For lab validation, I referred to the public PoC published by 7h30th3r0n3. The repository demonstrates the JSON:API-to-PostgreSQL path and credits michaelmaturi with discovering the original vulnerability. I recommend reading the source before running any security tool; it makes the request flow much easier to understand.

The turning point: the response changed

I tested only against an environment where I had permission. First, I used the boolean-based check and compared the true and false responses. One condition returned five records; the other returned none. That was the small signal I was looking for. The request was not simply producing an error — it was changing the query logic.

At that stage, the issue moved from 'possibly vulnerable' to confirmed in my lab. The next controlled test showed the real impact: data belonging to Drupal's administrator account could be recovered from the database.

I have blurred the target, endpoint inventory, username, email address, and password hash in the screenshots. Even test data can reveal more than expected once an image is published.

How to check your environment

Before doing anything complicated, check two basics: the Drupal Core version and the database driver. If the site is not using PostgreSQL, this particular injection path does not apply. If it is using PostgreSQL, compare the installed release with the patched-version table above.

A PostgreSQL-backed Drupal configuration normally uses the pgsql driver. Do not paste the complete settings.php file into a ticket or public forum because it may contain credentials and secrets.

Remediation

The correct fix is to update Drupal Core. Do not depend on a WAF rule as the permanent answer. For many Composer-managed sites, the update looks like this, although the package list must match the project's composer.json:

I would still take a verified backup and test the change in staging, but I would not leave this patch waiting for the next monthly cycle. After deployment, confirm the version again and rebuild Drupal's cache.

A WAF may buy some time by blocking familiar payload patterns. It should be treated as temporary risk reduction, not remediation. Different encodings and request-normalization behavior can make a signature easy to miss.

Patch, then investigate

There is one more step that is easy to overlook: patching does not tell you whether somebody already exploited the site. If a vulnerable instance was reachable from the internet, I would review:

· Requests to JSON and JSON:API endpoints containing unusual nested filter structures.

· PostgreSQL errors, timing anomalies, and unexpected query patterns.

· New or modified administrator accounts, roles, and permissions.

· Unexpected changes to Drupal modules, themes, PHP files, and scheduled tasks.

· Outbound connections from web and database servers.

· Unexpected access to configuration files, credential stores, and sensitive tables.

Preserve relevant web-server, Drupal, WAF, database, authentication, and operating-system logs. If compromise is suspected, rotate database credentials, privileged passwords, API tokens, and other secrets accessible to the application, and follow the organization's incident-response process.

Defensive hardening

· Grant the Drupal database account only the permissions the application needs.

· Do not expose PostgreSQL directly to the public internet.

· Centralize application, proxy, database, and authentication logs.

· Alert on abnormal JSON:API activity and repeated database errors.

· Remove unused modules and disable unnecessary public endpoints.

· Keep Drupal Core and Composer dependencies on supported branches.

· Maintain tested backups and a documented incident-response playbook.

What developers should learn

The bug is a useful reminder that saying 'we use prepared statements' is not the end of a SQL-injection review. Prepared statements protect values when the query structure stays fixed. They do not automatically protect table names, column names, operators, sorting instructions, query fragments, or placeholder names.

If user input can affect one of those structural pieces, use a strict allowlist or map it to a fixed internal value. This matters even more in shared framework code: one unsafe query-building helper can quietly expose many endpoints.

Final thoughts

CVE-2026–9082 is serious because the attacker can be anonymous, the vulnerable path is reachable over the network, and the impact reaches the database. Public PoCs and confirmed exploitation make the patching window even smaller.

If you manage Drupal with PostgreSQL, check the version today, apply the official update, and look through the logs instead of assuming the patch is the end of the story.

I hope this practical breakdown helps you understand the issue and validate your own authorized lab. If you found it useful, feel free to share it with another Drupal administrator or security researcher. Happy hacking — and always test responsibly.