psqlODBC EUVD-2026-115379

Requires all of: a Unix-like host, psqlODBC logging explicitly enabled (not the default state), and a local authenticated user account on the same machine as the victim. The driver writes logs to /tmp with predictable names derived from program name, user name, and process ID, using default (typically world-readable) permissions, and follows symlinks when opening them - so the concrete prerequisites are (a) a victim actively running psqlODBC with logging on, and (b) attacker ability to read the victim's log file or pre-place a symlink at the predictable /tmp path. Limiting factors: no remote vector (local only), the attacker must already be authenticated as a separate local user, logging is a non-default opt-in, and the symlink-append path depends on timing/predicting the victim's log filename, which drives the high attack complexity. Affected versions are those before psqlODBC 18.00.0006.

This is a moderate, locally-exploitable issue rather than an urgent priority. The CVSS 3.1 vector (AV:L/AC:H/PR:L/UI:N) confirms exploitation requires local access by an already-authenticated low-privileged user, with high attack complexity, which caps the base score at 5.3 (Medium). The vuln.today decision label is 'this_month' - not 'act_now' or 'emergency' - which is consistent with a local information-disclosure/file-tampering flaw. No EPSS score, no CISA KEV listing, and no PoC or exploit reference are present in the supplied data, so there is no signal of active exploitation or weaponization; absence of these is not itself an error, but it means the only exploitation evidence is the vendor (PostgreSQL) advisory describing the mechanism. The two impacts described - reading another user's query logs (C:H) and symlink-redirected log appending with the victim's privileges (I:L) - are real but depend on a victim actively running psqlODBC with logging enabled. Net: a legitimate issue to patch on a normal maintenance cycle, not a high-CVSS/low-real-risk false alarm, but also not an internet-facing emergency given the local attack vector and non-default logging requirement.

On a shared Unix host, a logged-in local user pre-creates a symbolic link at the predictable /tmp log path that psqlODBC will use for another user, so that when the victim runs an ODBC-backed application with logging enabled the driver appends log data (containing query text and data) to an attacker-chosen file with the victim's privileges; alternatively the attacker simply reads the victim's world-readable log file directly. No public exploit code is identified in the available data, and high attack complexity reflects the dependence on the victim actively logging.