CVE-2026-116241 in pgAdmin
Summary
by MITRE • 10/30/2026
pgAdmin 4's Import/Export Data tool wraps a user's query export in a psql \copy (...) TO command and checks that the query's parentheses are balanced so that nothing can escape the wrapper. The check rejected a backslash inside a single-quoted string, but not inside a double-quoted identifier, where it treated the next double quote as closing the identifier. psql's \copy parser applies the connection's escape character to whichever quote opened a token, so with standard_conforming_strings off a backslash-escaped double quote does not close the identifier. pgAdmin's and psql's view of the quoting then diverged, a closing parenthesis hidden from the check ended the \copy (...) wrapper, and a following TO PROGRAM clause was executed by psql on the pgAdmin host, as the operating-system account running pgAdmin, before the server rejected the statement. An ordinary database role can turn standard_conforming_strings off for itself, and the Import/Export Data permission is granted to non-administrators by default.
This is a bypass of the fix for CVE-2026-17566. The fix rejects any backslash inside a double-quoted identifier, as was already done for single-quoted strings, since its meaning depends on a server setting that cannot be known reliably when the query is validated.
This issue affects pgAdmin 4: before 9.19.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/30/2026
The vulnerability in pgAdmin 4 stems from an inconsistency between how the application validates SQL queries and how the PostgreSQL client utility psql interprets them during data import or export operations. Specifically, the Import/Export Data tool constructs a command using the psql \copy directive to wrap user-supplied query exports. To prevent code injection, the tool attempts to ensure that parentheses within the user's query are balanced so they do not prematurely close the wrapper and allow arbitrary commands to be executed via subsequent clauses such as TO PROGRAM. The validation logic correctly rejects backslashes inside single-quoted strings but fails to account for their behavior in double-quoted identifiers under specific server configurations.
The core technical flaw arises from a divergence in parsing rules between pgAdmin's validator and psql's parser regarding escape characters. When standard_conforming_strings is set to off, which allows non-standard string literal syntax where backslashes act as escape characters, the interpretation of quotes changes significantly. In this mode, a backslash preceding a double quote does not terminate the identifier but instead escapes it. However, pgAdmin’s validation logic treats any closing double quote as ending the identifier regardless of whether it is escaped by a preceding backslash. This discrepancy allows an attacker to craft a query where a backslash-escaped double quote hides a closing parenthesis from pgAdmin's check while still being interpreted correctly by psql.
This misalignment enables a command injection attack that bypasses previous security fixes, including those intended for CVE-2026-17566. By exploiting this parsing difference, an attacker can inject arbitrary SQL commands or operating system commands through the TO PROGRAM clause of the \copy directive. Because psql executes these commands on the host machine running pgAdmin with the privileges of the user account under which pgAdmin is operating, the impact is severe. The attack does not require administrative database roles; it only requires permission to use the Import/Export Data feature, which is granted by default to non-administrative users in many configurations.
The operational impact includes remote code execution on the server hosting pgAdmin if an attacker can supply malicious input through this interface. This represents a significant security risk as it allows privilege escalation from a standard database user level to full system access depending on the permissions of the pgAdmin process owner. The vulnerability highlights the dangers of relying solely on client-side or application-level validation when interacting with tools that have their own complex parsing logic dependent on server configuration states like standard_conforming_strings.
Mitigation strategies should focus on updating pgAdmin 4 to version 9.19 or later, where the fix explicitly rejects backslashes inside double-quoted identifiers just as it does for single-quoted strings. This ensures consistent behavior regardless of the database's string literal settings. Additionally, administrators should review and restrict permissions for the Import/Export Data tool if possible, ensuring that only trusted users have access to features that generate external process commands. Enforcing standard_conforming_strings on at the server level can also reduce the attack surface by preventing individual sessions from altering this critical setting, although application-level validation remains essential as a defense-in-depth measure against such parsing inconsistencies.
From a classification perspective, this vulnerability aligns with CWE-94 Improper Control of Generation of Code or Command Injection and CWE-602 Client-Side Enforcement of Server-Side Security Controls. In the context of the MITRE ATT&CK framework, it relates to techniques involving command injection through application interfaces, specifically leveraging misconfigurations in how input is parsed versus executed by downstream components like psql. The failure lies not just in weak validation but in a fundamental mismatch between security checks and runtime execution environments, underscoring the need for rigorous testing across different database configuration states during development and quality assurance processes.