psqlODBC 18.00.0006 fixes two more memory corruption flaws

psqlODBC 18.00.0006 fixes two more memory corruption flaws

3 November 2026: psqlODBC, the official ODBC driver that lets Windows and Linux applications, reporting tools and spreadsheets talk to PostgreSQL, has two new advisories, both rated High at 7.5 and both fixed in version 18.00.0006: CVE-2026-120057, in which a server can overwrite memory in the client through a large-object read, and CVE-2026-120061, a stack overflow in the parser for ODBC escape sequences. Every release up to 18.00.0005 is affected, which means the version we reported on last month for its own heap corruption fix is itself now out of date.

When the server is the attacker

CVE-2026-120057 turns the usual direction of a database attack around. When an application reads a large object, psqlODBC copied the server's reply into the application's buffer using the length the server sent, without checking it against the buffer size. A server that is not trusted under the connection's SSL settings, or anyone able to sit in the middle of an unverified connection, can send back more bytes than the buffer holds and overwrite neighbouring memory in the client with bytes of its choosing. The advisory says fetching any large-object column is enough.

The fix passes the caller's buffer size down, clamps the copy and rejects short replies. Until the driver is updated, the maintainers' workaround is to fetch large-object columns only from servers authenticated with sslmode=verify-full, or with GSSAPI encryption required through pqopt={gssencmode=require}.

Escape sequences in untrusted SQL

CVE-2026-120061 is in the code that rewrites ODBC escapes such as {fn ...}, {d ...}, {t ...} and {ts ...} into PostgreSQL syntax. The parser stored the argument offsets of a {fn} escape in a fixed, uninitialised 16-entry array on the stack with no bound, so an escape with too many arguments overflows it, and a reference to a missing argument copies arbitrary bytes into the query. The copy of a date, time or timestamp escape also wrote one byte past a 128-byte buffer. The risk is to applications that forward SQL text they did not write, such as reporting front ends or integration tools that accept user queries. The workaround is to keep untrusted SQL away from the driver, or to reject text containing ODBC escapes before it reaches it.

Both flaws were found in an internal review of the psqlODBC source, and neither advisory reports exploitation.

Rolling the driver out

The driver is installed per machine, often bundled by an application installer or pushed by desktop management, so an update on the database server fixes nothing. Inventory where psqlODBC is installed (BI desktops, ETL servers, Windows application servers), check the version against 18.00.0006, and update. For clients that read large objects across networks you do not control, moving connection strings to sslmode=verify-full is worth doing anyway, since it is the condition both this flaw and impersonation attacks generally depend on.

Related on TrustList:

• PostgreSQL 19 now due on 19 November after late feature reverts
• PgBouncer 1.26.1 fixes a SCRAM login bypass and two hang bugs
• psqlODBC 18.00.0005 fixes heap corruption from oversized parameter lists

Sources

• psqlODBC GHSA-qhmr-5339-q33r: Large-object read overflows the application buffer (CVE-2026-120057), 3 November 2026
• psqlODBC GHSA-hfm6-qfx8-v4xq: ODBC escape parser stack buffer overflow (CVE-2026-120061), 3 November 2026
• psqlODBC releases: REL-18_00_0006, 2 November 2026
• Canadian Centre for Cyber Security: PostgreSQL security advisory (AV26-1115), 3 November 2026