CVE-2026-120059 in psqlODBC
Summary
by MITRE • 11/02/2026
For an updatable cursor over a table without OIDs that has an auto-increment int4 column, psqlODBC places that column's name, as reported by the server, into a printf-style format string. It later expands that string with one argument while it builds the WHERE clause of its positioned SELECT, UPDATE, and DELETE statements. A column name that contains format directives makes the driver read unrelated memory, which can crash the application or copy client memory into query text sent to the server. The name can come from a server not trusted under current SSL settings, or from any database user who can create a table that the application reads with an updatable cursor. Versions before psqlODBC 18.00.0006 are affected.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 11/02/2026
The vulnerability identified in versions of psqlODBC prior to release 18.00.0006 represents a critical input validation failure within the driver's handling of dynamic SQL generation for updatable cursors. This flaw specifically targets scenarios where an application utilizes an updatable cursor over a table that lacks Object Identifiers (OIDs) and contains an auto-incrementing integer column defined as int4. Under these specific conditions, the psqlODBC driver retrieves the name of this auto-increment column from the PostgreSQL server metadata to construct the WHERE clause for positioned SELECT, UPDATE, and DELETE operations. The core technical defect lies in how this retrieved column name is processed; instead of being treated strictly as a literal string identifier or properly escaped parameter value, it is incorrectly inserted into a printf-style format string used by the driver's internal logic.
This architectural oversight creates a classic Format String vulnerability, which falls under CWE-134: Use of Externally-Controlled Format String. When the column name contains special characters that function as format directives, such as percent signs followed by specific letters like s or x, the C standard library printf family functions interpret these sequences rather than treating them as literal text. During the expansion of this string with a single argument intended for other parts of the query construction, any unescaped format specifiers within the column name cause the driver to read additional arguments from the stack that were not explicitly provided by the developer's code. This results in an out-of-bounds memory access where the application reads unrelated data from its own process memory space.
The operational impact of this vulnerability is severe and multifaceted, encompassing both confidentiality breaches and availability disruptions. Because the driver reads arbitrary memory locations based on the format directives present in the column name, sensitive information stored within the client application's memory can be leaked into the query text sent to the database server. This effectively allows an attacker who controls the table structure or the data schema to exfiltrate confidential data from the host running the psqlODBC driver. Furthermore, if the format string manipulation leads to invalid pointer dereferences or stack corruption, it can cause immediate application crashes, leading to a denial of service for users relying on that specific database connection. The severity is compounded by the fact that this behavior occurs during standard cursor operations, making it difficult to distinguish from normal traffic without deep inspection.
The attack surface for exploiting this vulnerability includes two primary vectors depending on the deployment context. First, if the client connects to a PostgreSQL server over an unencrypted or improperly configured SSL connection, an attacker with network-level access could manipulate the metadata returned by the server, injecting malicious column names into the response stream. Second, and more commonly in enterprise environments, any database user who possesses the privilege to create tables can exploit this flaw locally within their own schema. By creating a table with an auto-increment int4 column named using format specifiers such as %s or %x, and then having a vulnerable application open an updatable cursor on that table, the attacker triggers the memory read vulnerability without needing network access or elevated privileges beyond basic DDL rights.
To mitigate this risk, organizations must immediately upgrade psqlODBC to version 18.00.0006 or later, where the developers have corrected the handling of column names by ensuring they are properly escaped and not passed directly into format strings. In environments where upgrading is temporarily delayed, defensive coding practices should be enforced within application logic that interacts with ODBC drivers. This includes avoiding updatable cursors on tables controlled by untrusted users or implementing strict schema validation to reject table structures containing suspicious naming conventions. Additionally, ensuring all database connections utilize strong SSL/TLS encryption prevents network-based attackers from injecting malicious metadata into the communication stream, thereby reducing one of the two primary exploitation vectors associated with this CWE-134 flaw.