CVE-2026-120061 in psqlODBCinfo

Summary

by MITRE • 11/02/2026

The psqlODBC parser for ODBC escape sequences in application SQL text writes the argument offsets of a {fn} escape into a fixed 16-entry stack array without a bound and does not initialize the array. An escape with too many arguments overflows the stack, and a reference to an unsupplied argument copies arbitrary bytes into the query. The copy of a {d}, {t}, {ts}, or {escape} body also writes one byte past a 128-byte stack buffer. An application that forwards untrusted SQL text to the driver exposes its process to memory corruption. Versions before psqlODBC 18.00.0006 are affected.

Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Analysis

by VulDB Data Team • 11/02/2026

The vulnerability identified in the PostgreSQL ODBC driver, commonly referred to as psqlODBC, represents a critical class of memory safety issues rooted in improper handling of SQL escape sequences within application-supplied query text. The core technical flaw lies in the parser's management of stack-allocated buffers when processing function-style escape sequences denoted by the {fn} syntax. Specifically, the driver attempts to store argument offsets for these escapes into a fixed-size array comprising only sixteen entries. This allocation is performed without implementing any bounds checking mechanism to verify that the number of arguments provided in the SQL text does not exceed this hardcoded limit. Furthermore, the array itself is uninitialized at the time of its creation, introducing an additional layer of risk related to undefined behavior and potential information leakage if accessed before proper initialization occurs.

When a malicious or poorly constructed SQL query contains an escape sequence with more than sixteen arguments, the parser proceeds to write offset data beyond the boundaries of the allocated stack array. This action results in a classic buffer overflow condition on the application's call stack. Because this memory corruption occurs within the process space of the client application invoking the ODBC driver, it can lead to severe consequences such as arbitrary code execution, denial of service through segmentation faults, or privilege escalation if the compromised process operates with elevated permissions. The lack of boundary validation allows an attacker who controls the input SQL text to overwrite adjacent stack memory, potentially overwriting return addresses or function pointers that dictate control flow during program execution.

In addition to the overflow in the argument offset array, there is a secondary vulnerability involving other escape sequences such as {d} for dates, {t} for times, {ts} for timestamps, and the generic {escape} sequence. The parsing logic for these constructs writes data into a 128-byte stack buffer but fails to account for all possible input lengths, resulting in an off-by-one error where one byte is written past the end of the allocated buffer. While this specific overflow may seem minor due to its single-byte nature, it still constitutes a memory corruption vulnerability that can be exploited under certain conditions to corrupt metadata or trigger crashes. The combination of uninitialized variable usage and multiple out-of-bounds write operations creates a complex attack surface where different vectors might interact unpredictably during runtime analysis.

The operational impact of these vulnerabilities is significant for any software architecture that accepts untrusted SQL text from external sources, such as web applications, API endpoints, or user-facing interfaces that construct database queries dynamically. By forwarding maliciously crafted escape sequences to the psqlODBC driver, an attacker can compromise the integrity and availability of the host application. This exposure undermines the security boundary between the client application and the backend PostgreSQL database server, allowing for potential remote code execution if the application runs with sufficient privileges or interacts with sensitive system resources. The risk is particularly acute in environments where input validation on SQL syntax is not rigorously enforced prior to driver invocation.

To mitigate these risks, organizations must immediately upgrade their psqlODBC installations to version 18.00.0006 or later, which addresses the buffer management flaws by implementing proper bounds checking and initializing stack arrays before use. In addition to upgrading the driver, developers should enforce strict input validation on all SQL text received from untrusted sources, ensuring that escape sequences conform to expected argument counts and formats. Employing parameterized queries where possible can also reduce reliance on complex string parsing logic within the application layer. From a defensive perspective, deploying runtime protection mechanisms such as stack canaries or address space layout randomization can help detect exploitation attempts of these memory corruption vulnerabilities before they achieve full control over the process execution flow.

This vulnerability aligns with Common Weakness Enumeration categories CWE-120 Buffer Copy without Checking Size of Input and CWE-787 Out-of-bounds Write, reflecting its nature as a classic buffer overflow issue. Furthermore, it relates to CWE-94 Improper Control of Generation of Code SQL Injection in the context of how untrusted input is processed by database drivers. In terms of adversary tactics, this flaw supports techniques associated with ATT&CK ID T1059 Command and Scripting Interpreter if exploited for code execution, or potentially T1203 Exploitation for Client Execution depending on the delivery method. The failure to initialize variables also touches upon CWE-457 Use of Uninitialized Variable, which contributes to the unpredictability of the exploit's behavior and complicates defensive analysis efforts.

Responsible

PostgreSQL

Reservation

10/30/2026

Disclosure

11/02/2026

Moderation

accepted

EPSS

0.00000

KEV

no

Activities

very low

Sources

Interested in the pricing of exploits?

See the underground prices here!