psqlODBC EUVD-2026-115371

Exploitation requires (1) the psqlODBC driver configured with the UseDeclareFetch option enabled - the vulnerable cursor/FETCH path is explicitly reachable only in that mode; and (2) the client connecting to a PostgreSQL server that is 'not trusted under current SSL settings,' meaning an attacker must operate or impersonate the backend (a malicious server or MITM where SSL trust is not enforced). The trigger is a malicious server answering a later FETCH with more columns than the first result (heap over-write), or a keyset reply with fewer columns than the key fields (unsigned field-count underflow). LIMITING FACTORS: per the CVSS vector, user interaction is required (UI:R) because a victim must initiate the vulnerable cursor connection, and attack complexity is high (AC:H) because the attacker must already be in a trusted-server or MITM position; deployments that enforce strong SSL/TLS server verification and that do not enable UseDeclareFetch are not exposed.

This is a genuine memory-corruption vulnerability (CWE-787, out-of-bounds write) but one whose real-world risk is tempered by its unusual threat model rather than a straightforward high-CVSS remote bug. The supplied CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H, 7.5) encodes the key frictions: AC:H and UI:R mean exploitation is not a simple remote hit - it requires a victim to initiate a connection and an attacker positioned as a PostgreSQL server that is 'not trusted under current SSL settings,' i.e. a malicious or impersonated backend (MITM or rogue server). PR:N (unauthenticated) is correct in the sense that the server side needs no client credentials. The decision label is 'this_week' (vuln.today), which signals prompt but not emergency handling, consistent with a serious-but-conditional flaw. CRITICAL DATA GAPS: no EPSS score is provided, so exploitation probability cannot be quantified; the CVE is NOT in CISA KEV, so there is no evidence of active exploitation; and the sole reference is a GitHub security advisory, not a published proof-of-concept. These signals are coherent rather than conflicting - high technical impact but a constrained trigger (malicious-server + UseDeclareFetch) - so this warrants timely patching for environments using psqlODBC against untrusted or network-reachable servers, but it is not a drop-everything internet-wide worm candidate.

An attacker who can impersonate or substitute a PostgreSQL server (for example via a MITM when SSL trust is weak, or by luring a client to connect to a rogue backend) waits for a psqlODBC client with UseDeclareFetch enabled to run a cursor query. After the first result sizes the driver's row cache, the attacker answers a later FETCH with more columns than the first reply, causing the driver to write tuple records past the end of the heap allocation. No public exploit identified at time of analysis; only a vendor security advisory is referenced.