CVE-2026-120057 in psqlODBC
Summary
by MITRE • 11/02/2026
psqlODBC copies the reply to a large-object read (loread) into the application's buffer using the length sent by the server, without comparing it to the buffer size. A server not trusted under current SSL settings, or a man-in-the-middle, can return more bytes than the buffer holds and overwrite adjacent memory in the client process with server-chosen bytes. Fetching any large-object column is sufficient to trigger it. Versions before psqlODBC 18.00.0006 are affected.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 11/02/2026
The vulnerability identified in PostgreSQL ODBC driver versions prior to 18.00.0006 represents a critical buffer overflow condition rooted in improper input validation during the handling of large object data retrieval operations. Specifically, when an application requests data from a database using the loread function, the client-side library allocates a fixed-size buffer intended to hold the returned payload. The flaw occurs because the driver blindly trusts the length field provided by the server without performing any bounds checking against the actual capacity of the allocated memory region. This architectural oversight creates a direct pathway for remote code execution or denial of service if an attacker can manipulate the data source, as there is no mechanism to truncate oversized responses that exceed the buffer limits.
From a technical perspective, this issue classifies under CWE-120 Buffer Copy without Checking Size of Input which indicates that software copies input into a buffer without verifying that the input fits within the boundaries of the buffer. In the context of ODBC drivers, large objects are often used to store substantial amounts of binary or text data such as images documents or logs. When a client initiates a read operation for any column defined as a large object type, the driver prepares a local memory segment based on expected parameters rather than dynamic validation of incoming stream sizes. If the server responds with a length value that exceeds the pre-allocated buffer size, subsequent write operations will spill over into adjacent memory locations. This out-of-bounds write can corrupt stack variables heap structures or control flow data depending on where the buffer resides in memory space.
The operational impact of this vulnerability is severe particularly for applications relying on untrusted database connections or those operating within compromised network environments. An attacker positioned as a man-in-the-middle who intercepts traffic between the client and server could modify query responses to include artificially inflated length fields paired with malicious payloads. Alternatively if SSL settings are misconfigured allowing connection to servers not trusted under current certificate validation policies an adversary controlling such a rogue database instance could exploit this flaw directly during normal data retrieval workflows. Successful exploitation allows for arbitrary memory overwrite which typically leads to application crashes resulting in denial of service or potentially enables remote code execution by overwriting function pointers return addresses or other critical control structures within the process address space.
Mitigation strategies must focus on both immediate patching and long-term architectural improvements. The primary remediation is upgrading psqlODBC to version 18.00.0006 or later where this validation logic has been corrected to ensure that incoming data lengths are strictly compared against buffer capacities before copying occurs. For environments unable to upgrade immediately, network-level controls such as strict SSL/TLS enforcement with verified certificate chains can prevent connection to untrusted servers thereby reducing the attack surface associated with man-in-the-middle scenarios. Additionally implementing application-layer input validation where possible and ensuring that large object handling routines use dynamic memory allocation based on actual data size rather than fixed buffers can provide defense in depth against similar vulnerabilities across other database drivers or custom implementations.
This vulnerability aligns with ATT&CK technique T1059 Command and Scripting Interpreter if exploitation leads to code execution as well as T1213 Data from Information Repositories since the initial vector involves retrieving data from a database system. The lack of size verification also reflects weaknesses in CWE-20 Improper Input Validation which underscores the need for rigorous sanitization checks at all boundaries between trusted and untrusted components within software systems especially when dealing with external network inputs that dictate internal memory operations.