psqlODBC CVE-2026-120064

Exploitation requires an application using psqlODBC that passes attacker-controlled column numbers or row indices into the affected ODBC entry points: SQLBindCol with a column number above 32767 (binding count wraps negative), a negative SQL_DESC_COUNT set on an application row descriptor, SQLColAttribute called with a very large column number, or SQLSetPos(SQL_ADD) with a row number not checked against the rowset size. This is NOT a default-configuration remote flaw - the limiting factor is that the host application must relay untrusted index values to these APIs, which most applications (using fixed, trusted column numbers) do not do, explaining the AC:H complexity. Affected: all versions before psqlODBC 18.00.0006; the fix is upgrading to 18.00.0006.

The input CVSS 3.1 vector (AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H, base 7.5) describes high impact across confidentiality, integrity and availability via out-of-bounds reads and writes, but tempers it with high attack complexity (AC:H) and low-privilege requirement (PR:L). The decisive caveat is in the description itself: exploitation only arises in an application that forwards UNTRUSTED column or row numbers to psqlODBC entry points. This is a library/driver flaw whose exploitability is entirely contingent on how the embedding application uses the ODBC API - most applications pass fixed, trusted column numbers and are therefore not exposed, which is consistent with the AC:H rating. No EPSS score is provided, so widespread-exploitation probability cannot be quantified. The CVE is NOT in CISA KEV (no active exploitation signal) and no PoC or exploit reference is present - only the vendor security advisory. The vuln.today decision label is 'this_week', i.e. prioritized but below act_now/emergency. Net: this is a genuine memory-corruption bug worth patching this week for anyone running affected psqlODBC behind applications that relay untrusted indices, but it is not a drop-everything internet-wide threat - the AV:N network vector is only reachable when the host application itself exposes the untrusted column/row values, which should be verified per application rather than assumed.

An application built on psqlODBC forwards an attacker-influenced column number (for example derived from a web request parameter) into SQLBindCol with a value above 32767, causing the binding count to wrap negative so that a later copy runs off the array; alternatively a negative SQL_DESC_COUNT, an oversized SQLColAttribute column number, or an SQLSetPos(SQL_ADD) row beyond the rowset drives a negative or out-of-range index. The result is an out-of-bounds read or write in the application process, potentially leaking memory or corrupting state toward code execution. No public exploit identified at time of analysis; only the vendor advisory is referenced.