Drupal PostgreSQL SQLi shows how SELECT-only injection becomes RCE

Drupal PostgreSQL SQLi shows how SELECT-only injection becomes RCE

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_libraries is 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.

References

1. Drupal PostgreSQL SQL Injection: From SELECT-Only to RCE
2. CVE-2026-9082
3. SA-CORE-2026-004
4. Ambionics CVE-2026-9082 Drupal PostgreSQL RCE