CVE-2026-120062 in psqlODBC
Summary
by MITRE • 11/02/2026
SQLSpecialColumns in psqlODBC splices the table and schema names it receives into its catalog query without escaping them, while the other catalog functions escape them. An application that passes an untrusted table or schema name to SQLSpecialColumns lets the caller execute arbitrary SQL with the privileges of the connection. Versions before psqlODBC 18.00.0006 are affected.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 11/02/2026
The vulnerability identified in PostgreSQL's ODBC driver, specifically within the implementation of the SQLSpecialColumns function, represents a critical injection flaw stemming from improper input validation and sanitization practices. In standard database interaction protocols, catalog functions that retrieve metadata about tables, columns, or constraints are expected to treat user-supplied identifiers such as table names and schema names as data rather than executable code. However, in versions of psqlODBC prior to 18.00.0006, the SQLSpecialColumns function fails to properly escape these identifiers before incorporating them into the underlying SQL query string sent to the database server. This behavior stands in stark contrast to other catalog functions within the same driver library, which correctly apply escaping mechanisms to prevent such injection attacks. The inconsistency creates a specific attack vector where an application developer or attacker who can control the input parameters for table and schema names can inject arbitrary SQL commands that will be executed with the privileges of the database connection used by the ODBC driver.
From a technical perspective, this flaw is classified under CWE-89, which denotes Improper Neutralization of Special Elements used in an SQL Command, commonly known as SQL Injection. The root cause lies in the failure to quote or escape identifiers that are embedded directly into dynamic SQL statements without proper delimiters or escaping sequences. When an untrusted source provides a table name such as users; DROP TABLE orders--, the driver concatenates this string directly into the query structure for retrieving special column information. Because the database engine interprets the semicolon and subsequent commands as part of the statement, it executes them alongside the intended metadata retrieval operation. This allows for unauthorized data access, modification, or destruction depending on the permissions granted to the specific database user account associated with the ODBC connection string.
The operational impact of this vulnerability is severe due to its potential for full system compromise within the context of the database server. An attacker leveraging this flaw can bypass authentication checks if they have valid credentials but limited privileges, escalate their access by executing administrative commands, or exfiltrate sensitive data from tables that were not intended to be queried through the specific application interface being exploited. Furthermore, because SQLSpecialColumns is often used in automated tools and applications for schema discovery and dynamic query generation, it may be invoked frequently with inputs derived from user-facing forms or API parameters, increasing the likelihood of successful exploitation in production environments where input validation might be lax or absent.
Mitigation strategies must focus on immediate patching and defensive coding practices. The primary remediation is to upgrade psqlODBC to version 18.00.0006 or later, where this specific escaping logic has been corrected to align with the security posture of other catalog functions in the library. For applications that cannot immediately update their dependencies, developers should implement strict input validation on all table and schema names passed to SQLSpecialColumns. This includes enforcing allowlists for known valid identifiers, rejecting inputs containing special characters such as semicolons or quotes unless they are part of a validated identifier format, and ensuring that any dynamic construction of database queries utilizes parameterized statements where supported by the ODBC driver's capabilities. Additionally, applying the principle of least privilege to the database user account used by the application can limit the blast radius if an injection attempt is successful, preventing attackers from executing administrative or destructive commands even if they manage to inject SQL code into the query stream.
This vulnerability aligns with MITRE ATT&CK technique T1059, Command and Scripting Interpreter, specifically under sub-techniques involving database command execution. It also reflects common patterns found in CWE-20, Improper Input Validation, where the system fails to verify that inputs conform to expected formats before processing them as part of a larger operational context. Security teams should audit their use of ODBC catalog functions and ensure that all dynamic SQL generation follows secure coding standards that prioritize neutralization of special elements over trust in input sources. Regular vulnerability scanning and code reviews focusing on database interaction layers are essential to detect similar inconsistencies across other parts of the application stack before they can be exploited by malicious actors seeking unauthorized access or data manipulation capabilities.