psqlODBC EUVD-2026-115370

Exploitation requires that the client either connect to a PostgreSQL server that is not trusted under its current SSL settings (e.g. SSL verification not enforced) or that an attacker achieve a man-in-the-middle position on the connection; in either case the attacker must control the server's reply bytes. The client application must fetch a large-object column, which issues the loread call whose over-long reply triggers the unchecked copy - fetching any large-object column is sufficient. Limiting factors that reduce real-world exposure: a strictly SSL-verified connection to a trusted server is not exploitable, the application must actually use large objects, and user/application interaction (the fetch) is required (UI:R); no authentication of the attacker is needed (PR:N) but a network position or rogue server is.

This is a moderate-to-serious but conditional client-side memory-corruption flaw, not a mass-exploitation emergency. The input CVSS vector (CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H, base 7.5) is internally consistent with the description: AV:N reflects that a network-positioned attacker (MITM) or a malicious server delivers the oversized reply, AC:H reflects the dependency on the client not trusting the server under its SSL settings or on an attacker achieving a MITM position, UI:R reflects that the client application must actually fetch a large-object column, and C:H/I:H/A:H reflect that the server controls the bytes written past the buffer. No EPSS score and no KEV listing are present in the input, and CISA KEV status is therefore not asserted; the only reference is the PostgreSQL GHSA advisory, which is an advisory rather than verified working exploit code, so there is no public exploit identified at time of analysis. The vuln.today decision label is 'this_week', which positions this as a prompt-but-not-emergency patching priority. The practical risk is bounded by the need for an attacker-controlled or attacker-interposed PostgreSQL server and by the client using large objects; against a trusted, properly SSL-verified server the flaw is not reachable. Missing signals to note explicitly: EPSS probability is absent, KEV status is absent, and no PoC is confirmed - so prioritization here rests on CVSS and the vendor decision label rather than observed exploitation.

An attacker who operates a malicious PostgreSQL server (that the client does not strictly verify under its current SSL settings) or who achieves a man-in-the-middle position on the connection waits for the client application to read a large-object column via loread. The server returns a reply whose declared length exceeds the client's buffer; psqlODBC copies that many server-chosen bytes into the undersized buffer, overwriting adjacent memory in the client process. No public exploit is identified at time of analysis; the only reference is the vendor advisory.