PostgreSQL CVE-2026-16239

Exploitation requires a valid PostgreSQL database credential - any account holding LOGIN privilege and CONNECT access to the target database is sufficient; no superuser, schema-owner, or elevated role is needed. The triggering mechanism (re-declaring a named cursor with a different type) uses standard SQL cursor lifecycle statements (DECLARE, CLOSE) that are available to all non-restricted database users by default, with no special configuration, extensions, or non-default features required to be enabled. What limits exploitation: the attacker must possess a valid database login credential - unauthenticated network access alone is not sufficient (PR:L per CVSS vector). The impact scope is bounded to the PostgreSQL OS user account (S:U), so host-level privilege escalation beyond that account is not directly provided by this CVE. Deployments that restrict CONNECT privileges to tightly controlled application accounts and block direct user access to the database reduce - but do not eliminate - the exploitable population.

The NVD-assigned CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, score 8.8) accurately reflects the attack profile: the vulnerability is reachable over the network, requires low complexity, demands only a low-privileged authenticated session, and results in full confidentiality, integrity, and availability compromise of the database process. Scope is unchanged (S:U), bounding direct impact to the PostgreSQL OS account, but that account routinely has read/write access to all database files and significant host filesystem access, making the practical impact severe. No EPSS score was included in the source intelligence, so probabilistic exploitation likelihood cannot be quantified; this is a gap. No CISA KEV listing and no confirmed POC exist at time of analysis, which modestly tempers urgency compared to actively exploited flaws. However, the extremely low barrier - any valid database credential suffices, and the triggering mechanism is expressible in plain SQL with no binary tooling - means the exploitation complexity delta between description and working exploit is narrow. This is a genuine high-priority patch, not a high-CVSS-but-low-real-risk scenario; the only meaningful limiting factor is requiring a valid database account.

An attacker with any valid PostgreSQL login - such as a compromised application service account or a low-privileged internal user - connects to the database over the network and issues a sequence of standard SQL statements: DECLARE a named cursor returning one column type, CLOSE it, then re-DECLARE the same cursor name with a different column type, triggering the type confusion in the portal memory structures. The resulting memory corruption can be leveraged to redirect PostgreSQL's execution flow and run attacker-controlled code as the OS user under which the database process runs, typically 'postgres', granting full access to all database files and the host account's filesystem scope. No public exploit code has been identified at time of analysis, but the attack requires only plain SQL and no binary exploitation tooling.