Lexfo's May 26, 2026 write-up on CVE-2026-9082 matters because it breaks a common defensive assumption: "SELECT-only" does not mean "read-only impact." The research starts from an unauthenticated Drupal Core SQL injection reachable through a public JSON:API collection filter, then shows how the same primitive can become server-side remote code execution when the injected PostgreSQL role is a superuser.
That distinction matters well beyond Drupal. Many teams still treat a constrained SQL injection as mainly a data exposure issue if the payload cannot stack statements freely. Lexfo's chain shows why that shortcut can fail when database-side superuser functions expose enough side effects to turn one expression into a much bigger exploit path.
What the research actually shows
The entry point in this case is CVE-2026-9082, tracked by Drupal as SA-CORE-2026-004. According to Lexfo, the vulnerable path sits in Drupal's PostgreSQL-specific handling of JSON:API filters, enabling a fully unauthenticated SQL injection against public collection endpoints.
The more important technical lesson comes after initial access. The article shows that an attacker who can evaluate a PostgreSQL expression such as (SELECT ...) as a PostgreSQL superuser may not need classic stacked queries, COPY ... TO PROGRAM, CREATE EXTENSION, LOAD, or DO statements to reach code execution.
Instead, the chain stays inside a single generated SELECT and abuses privileged PostgreSQL functions to:
- write a native module to a server-side path
- modify
session_preload_libraries - trigger configuration reload
- wait for or force a fresh backend
- execute attacker-controlled code through
_PG_init() - read command output back with
pg_read_file()
That is a stronger outcome than many defenders associate with a supposedly constrained vulnerability class.
Why "SELECT-only" is a dangerous label
Security teams often use "SELECT-only" as shorthand for "no obvious path to operating-system impact." Lexfo's write-up is a reminder that the phrase describes syntax constraints, not security boundaries.
If the injection lands inside a scalar expression or subquery slot, the attacker may still be able to call powerful built-in functions. In PostgreSQL, that matters when the database role has superuser-equivalent privileges. At that point, the real question is not whether the payload can append a second SQL statement. The real question is whether the reachable functions can cause privileged side effects anyway.
This is the broader database lesson: once the server executes attacker-controlled expressions with elevated rights, "query shape" becomes less important than privilege, side effects, and environment configuration.
What conditions make the chain work
Lexfo does not present this as a universal one-click outcome for every PostgreSQL injection. The chain depends on several environmental conditions:
- the injection must evaluate a PostgreSQL expression or subquery
- the reached database role must be superuser or equivalent
- the transaction must not be read-only
- the PostgreSQL service account must be able to write and later load a compatible native library
- a fresh backend must be obtained so
session_preload_librariesis processed
Those constraints matter because they define where defenders should focus containment and hardening. This is not merely an application bug. It is an interaction between application input handling, database privilege design, and host-level access control.
Why the impact can spread beyond the database
The demonstrated code execution lands as the PostgreSQL operating-system user, not directly as the web application process. Even so, that is already a high-impact position.
From there, attackers may gain:
- direct access to database contents and application tables
- application secrets stored in the database or adjacent config paths
- opportunities for lateral movement toward the web tier, containers, or nearby internal services
- a foothold inside infrastructure that many organizations treat as trusted middleware
For Drupal environments specifically, full database control can be enough to alter administrative data, extract sensitive configuration, or seed additional compromise paths even before the operating-system layer is considered.
What defenders should do now
1. Patch Drupal instances affected by CVE-2026-9082
The first action is straightforward: if your environment uses Drupal with PostgreSQL and exposes the affected JSON:API path, treat this issue as urgent and validate that the vendor fix for SA-CORE-2026-004 is in place.
2. Reassess database privilege design
An application database role should not hold superuser privileges in normal operation. Lexfo's research is a practical demonstration of why that boundary matters. Reducing database privileges can sharply reduce what an attacker can do even if an application-layer injection exists.
3. Review writable and loadable paths on database hosts
The demonstrated chain depends on writing and loading a native module. That should push defenders to review filesystem permissions, module loading behavior, and whether database service accounts have broader write rights than they actually need.
4. Treat public JSON APIs as attack surface, not convenience plumbing
Internet-reachable collection filters, sort parameters, and query builders deserve the same scrutiny as login forms and upload endpoints. They are part of the broader attack surface, especially when they feed complex ORM or query-builder behavior.
5. Hunt for risky architectural assumptions
If your internal threat model still says "SELECT-only SQLi is probably just disclosure," update it. The safer model is conditional: impact depends on privilege, available functions, transaction mode, and surrounding host controls.
The bigger lesson
The most useful takeaway from Lexfo's research is not just that Drupal had a bad SQL injection. It is that database-side privileges can quietly turn a constrained application bug into an operating-system-level execution path.
That is why defenders should stop reading "SELECT-only" as a comfort label. In real environments, the gap between expression evaluation and code execution can be much smaller than it appears when the database role is too powerful and the surrounding system is permissive enough to help the chain along.
Does this mean every PostgreSQL SQL injection becomes RCE?
No. Lexfo's chain depends on specific conditions, including superuser-equivalent database rights, a writable and loadable server-side path, and a fresh backend that processes the preload setting.
Is the lesson only relevant to Drupal?
No. Drupal provides the entry point in this case, but the PostgreSQL technique is broader. The core lesson applies anywhere an attacker can evaluate a controlled PostgreSQL expression with overly powerful privileges.
Why is database privilege design so important here?
Because the demonstrated path depends on superuser-only capabilities. Reducing database privileges can turn a severe application bug into a materially smaller blast radius.
