PostgreSQL CVE-2026-15741

Exploitation requires the attacker to be an authenticated PostgreSQL database user with ownership of at least one database object (e.g., a function, operator, or custom type) in a database that a superuser or privileged DBA user will subsequently subject to a deparse consumer operation. The critical trigger is a superuser (or privileged user) running pg_dump against the database, using psql's \sf command on the hostile object, or invoking any third-party tool that calls PostgreSQL's expression deparse APIs. Without that privileged deparse operation occurring - for example, in environments where pg_dump is never run by a superuser against databases with untrusted object owners - exploitation cannot complete. The CVSS vector supplied (PR:N) conflicts with this requirement; in practice, the attacker must be an authenticated database user with object ownership, which is a meaningful limiting condition.

The provided CVSS vector (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H, 8.8) contains a significant internal conflict: PR:N (no privileges required) directly contradicts the description's explicit prerequisite of being a database 'object owner,' which requires authentication and object ownership - at minimum PR:L. This appears to be an error in the NVD-supplied vector. Correcting PR to L and accounting for the scope change (regular user → superuser) would more accurately represent the realistic attack path. Despite this vector inconsistency, real-world risk remains elevated: UI:R (a superuser must run pg_dump or \sf) is the primary exploitation gate, but these operations are common and routine in production environments. No EPSS score was provided, no CISA KEV listing exists, and no public POC has been identified - all signals that reduce urgency compared to a KEV-listed flaw. However, for multi-tenant environments where untrusted users can own database objects, the privilege escalation path to superuser represents a critical internal trust boundary violation. The missing EPSS data limits quantitative exploitation probability assessment.

An attacker with a low-privilege PostgreSQL account - sufficient only to own a database object such as a function or custom type - crafts that object's definition to embed SQL injection payloads within an EXTRACT() expression. When a database administrator subsequently runs pg_dump to back up the database or uses psql's \sf command to inspect function source, the deparse layer processes the hostile object definition and the injected SQL executes with the DBA's superuser privileges. No public exploit code has been identified at time of analysis.