psqlODBC EUVD-2026-115378

Requires all of: an application using psqlODBC before 18.00.0006 that opens an UPDATABLE cursor; the target table has NO OIDs and has an auto-increment int4 column that the driver uses as the row identifier; and that column's name, as reported by the server, contains a double-quote character (the driver fails to double embedded quotes when wrapping the name). The attacker must be authenticated as a database user with privileges to CREATE a table the application subsequently reads with such a cursor, OR be a server that is not trusted under the client's current SSL settings. Limiting factors: exploitation is confined to these cursor/table conditions and to the application's own database privileges (scope unchanged), and it depends on the application actually performing positioned SELECT/UPDATE/DELETE operations - not merely connecting. The only complete fix stated by the vendor is upgrading to psqlODBC 18.00.0006 or later.

This is a genuine but conditional SQL injection (CWE-89) in psqlODBC, not a drive-by critical. The CVSS 3.1 vector (AV:N/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:H = 7.1 High) is internally consistent with the description: network-reachable (AV:N) but gated by high attack complexity (AC:H, the chain of preconditions - updatable cursor over an OID-less table with an auto-increment int4 column), low privilege (PR:L, the attacker must be a database user able to CREATE a table the application later reads, or a server untrusted under current SSL settings), and required user/application interaction (UI:R, the application must actually run the positioned SELECT/UPDATE/DELETE). No EPSS score, no CISA KEV entry, and no proof-of-concept or exploit reference were supplied - the sole reference is the vendor security advisory (GHSA-9cg8-r57h-h6jj) - so there is no public exploit identified at time of analysis and no quantitative exploitation probability to weigh. The vuln.today decision label is 'this_week', indicating elevated-but-not-emergency priority, which aligns with the signals: high impact once triggered, but meaningful preconditions and no evidence of active exploitation. Realistically this is a privilege-boundary / untrusted-input issue most relevant where untrusted users can create tables or where SSL trust is weak, rather than a mass-exploitable internet-facing flaw.

A low-privileged database user creates a table (no OIDs, with an auto-increment int4 column) whose column name embeds an unescaped double quote, then waits for or induces an application to open an updatable cursor over it; psqlODBC splices the malicious name into its keyset and positioned SELECT/UPDATE/DELETE statements, altering the SQL that runs with the application's privileges and changing which rows an UPDATE or DELETE touches. Alternatively, a server not trusted under the client's current SSL settings supplies the crafted column name. No public exploit is identified at time of analysis, and the high attack complexity reflects the specific cursor/table conditions that must line up.