psqlODBC EUVD-2026-115373

Exploitation requires the psqlODBC client (before 18.00.0006) to connect to a PostgreSQL server that is not authenticated under the client's current SSL settings - i.e., an sslmode weak enough to permit a rogue server or MITM to supply response data - and the attacker must control the server's replies to inject an oversized/underflowing row count in SQLBulkOperations, an unbounded index key count in SQLStatistics, or a truncated bytea octal escape sequence. Limiting factors: the attacker must be positioned as the server (not merely reach the client), the user/application must actively initiate the connection (UI:R), and the flaw does not apply where SSL settings already establish a trusted server; the realistic impact is a client-side crash (A:H) with only limited memory disclosure (C:L).

This is a genuinely medium-severity, lower-urgency issue rather than a high-priority emergency, and the signals are mostly consistent. The CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:H, base 5.9) reflects a reversed threat model: the attacker is a malicious or MITM PostgreSQL server, not a remote attacker hitting a listening service. AV:N applies because data arrives over the network, but AC:H and UI:R meaningfully constrain it - the victim client must initiate a connection to a server that is not authenticated under current SSL settings, and the attacker must control that server's responses. The dominant impact is availability (A:H, client crash) with only low confidentiality exposure (C:L) from the out-of-bounds reads and no integrity impact (I:N), consistent with CWE-125. No EPSS score was provided in the input, so probabilistic exploitation likelihood cannot be quantified; this absence should not be read as 'low risk,' only as missing data. There is no CISA KEV listing and no confirmed public exploit, and the vuln.today decision label is 'this_month' rather than act_now or emergency - all of which point to patch-on-normal-cadence rather than drop-everything urgency. The practical risk is concentrated in environments where clients connect to untrusted or unverified PostgreSQL endpoints (weak sslmode, potential MITM), where the primary realistic outcome is a denial of service against the client application.

An attacker who controls a PostgreSQL server (a rogue endpoint, or a MITM position when the client's SSL settings do not verify the server) returns responses carrying malicious row counts, index key counts, or truncated bytea octal escape sequences. When a psqlODBC client before 18.00.0006 calls SQLBulkOperations or SQLStatistics, or decodes the crafted bytea, the driver trusts those server-supplied sizes and reads out of bounds, crashing the client or exposing adjacent memory. No public exploit was identified at the time of analysis, and the high attack complexity plus required client connection to an untrusted server limit opportunistic use.