CVE-2026-120065 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 uses that column to identify rows. It places the column's name, as reported by the server, between double quotes in its keyset queries and in the WHERE clause of its positioned SELECT, UPDATE, and DELETE statements, without doubling any double quote in the name. A column name that contains a double quote therefore changes the SQL that the driver runs with the application's privileges, including which rows a positioned UPDATE or DELETE affects. Any database user who can create a table that the application reads with an updatable cursor can choose such a name, and so can a server not trusted under current SSL settings. Versions before psqlODBC 18.00.0006 are affected.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 11/02/2026
The vulnerability described constitutes a critical SQL injection flaw within the PostgreSQL ODBC driver, specifically affecting versions prior to 18.00.0006 when handling updatable cursors over tables lacking Object Identifiers and containing auto-increment integer columns. The root cause lies in how the psqlODBC driver constructs keyset queries and positioned update statements for row identification. To ensure compatibility with PostgreSQL's behavior regarding unquoted identifiers, the driver automatically wraps column names in double quotes within its generated SQL commands. However, this process fails to properly escape or sanitize any embedded double quote characters present in the actual database object name provided by the server. This lack of input validation allows an attacker who controls the table schema definition to inject arbitrary SQL code directly into the execution context of the application using the driver.
From a technical perspective, when an application opens an updatable cursor on such a table, psqlODBC generates WHERE clauses and positioned UPDATE or DELETE statements that reference the column name enclosed in double quotes. If the column name itself contains a double quote character, the resulting SQL string becomes syntactically malformed from the driver's intended logic but valid as malicious input to the database engine. For instance, if an attacker creates a table with a column named "id"quote"", the driver might generate a query like SELECT * FROM table WHERE "id""quote"" = value. This breaks out of the identifier context and allows subsequent SQL commands or comments to be appended, effectively altering the logic of the positioned operations. Consequently, the application's privileges are leveraged to execute unintended database actions, potentially leading to unauthorized data modification, deletion, or information disclosure depending on the specific injection payload crafted by the attacker.
The operational impact is severe because it bypasses traditional authentication and authorization controls at the driver level, relying instead on the trust relationship between the client application and the database server. Any user with CREATE TABLE privileges in a shared environment can exploit this vulnerability to compromise applications that use psqlODBC for data manipulation tasks involving auto-increment columns without OIDs. Furthermore, if SSL settings are not strictly configured to enforce certificate validation against a trusted Certificate Authority, an attacker performing a man-in-the-middle attack could also manipulate the server's response regarding column metadata, thereby injecting malicious identifiers into the driver's query generation process. This expands the threat surface beyond just local schema manipulation to include network-based attacks where the integrity of the connection is compromised.
This vulnerability aligns with CWE-89, which covers Improper Neutralization of Special Elements used in an SQL Command, commonly known as SQL Injection. The specific mechanism involves untrusted data influencing the structure of a command executed by a privileged process. In terms of the MITRE ATT&CK framework, this behavior facilitates techniques related to Data Manipulation and potentially Privilege Escalation if the injected commands allow for broader system access or bypass security controls within the database layer. It represents a classic case where driver-level assumptions about identifier safety are violated due to insufficient sanitization of metadata returned by the backend server.
Mitigation strategies must focus on immediate patching and defensive coding practices. The primary remediation is upgrading psqlODBC to version 18.00.0006 or later, where this specific escaping logic has been corrected to properly handle double quotes within column names. In environments where an upgrade is not immediately feasible, database administrators should enforce strict naming conventions that prohibit the use of special characters like double quotes in table and column names for any tables accessed via updatable cursors by applications using psqlODBC. Additionally, ensuring robust SSL/TLS configurations with mutual authentication or strong certificate pinning can prevent remote attackers from manipulating server responses to inject malicious metadata. Application developers should also consider implementing additional validation layers on the client side where possible, although relying solely on application-level checks is less effective than fixing the driver vulnerability itself given that the injection occurs during internal query construction by the library rather than through direct user input fields in the application code.