psqlODBC EUVD-2026-115380

Updatable cursors must be in use - they are enabled by default in psqlODBC, so a default client reading rows with such a cursor is in scope. To actually trigger the overflow, the attacker needs ONE of two concrete positions: (1) a PostgreSQL server that is not trusted under the client's current SSL/TLS settings (a malicious or MITM server able to send a crafted ctid/oid value of 32 bytes or more), or (2) a database account able to CREATE a view that defines its own column named ctid, which the application subsequently reads through an updatable cursor. Limiting factors: exploitation depends on holding one of those attacker positions rather than merely reaching the network service (hence AC:H); builds compiled with _FORTIFY_SOURCE only abort, reducing impact to denial of service; and confirmed impact is limited to stack memory corruption/crash with no demonstrated confidentiality or integrity compromise. Affected versions are all releases before psqlODBC 18.00.0006.

The input CVSS of 5.9 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H) frames this as a medium-severity, availability-only issue, and the surrounding signals agree that it is a real but non-emergency concern. AV:N with PR:N/UI:N looks superficially like a trivially remote bug, but the description constrains the 'network' reach sharply: exploitation requires either a PostgreSQL server that is not trusted under the client's current SSL settings (a malicious or man-in-the-middle server) or a database user privileged enough to create a view exposing its own ctid column that the application then reads with an updatable cursor - this is precisely why AC:H is appropriate. The vuln.today decision label is 'this_month' (not act_now/emergency). No CISA KEV listing is present, so there is no confirmed active exploitation; EPSS is not provided in the input and cannot be cited; and the only reference is the vendor GHSA advisory, so no public exploit is identified. The impact is scored availability-only: _FORTIFY_SOURCE builds abort (clean DoS), while non-fortified builds overwrite adjacent stack memory - the sources do not claim code execution, so any confidentiality/integrity/RCE outcome is unverified. Net: a legitimate issue worth patching on a normal cycle, elevated slightly because updatable cursors are on by default, but not a drop-everything priority given the attacker-position prerequisites and availability-only confirmed impact.

An attacker who controls a PostgreSQL endpoint the client connects to without strict SSL trust (or a low-privileged database user who creates a view with a column named ctid) arranges for a 32-byte-or-longer value to be returned in the hidden ctid or oid column. When psqlODBC reads that row through an updatable cursor, it copies the server-supplied length into a fixed 32-byte stack buffer without bounds-checking, overflowing it. On _FORTIFY_SOURCE builds the process aborts (denial of service); on other builds adjacent stack memory is overwritten. No public exploit was identified at time of analysis.