PostgreSQL EUVD-2026-57856

Exploitation requires a valid PostgreSQL database account with sufficient privileges to execute CREATE TYPE or similar DDL statements in the target schema (PR:L per CVSS vector - a low-privilege authenticated user). The attacker must specifically invoke one of two unguarded code paths: range subtype assignment (CREATE TYPE ... AS RANGE with a SUBTYPE = ... clause referencing the target type) or an SQL expression that references the type, causing an unauthorized pg_depend entry to be written. No special network position, elevated role, or non-default configuration is required beyond holding a low-privilege database account with CREATE access. Limiting factors: the impact is confined solely to blocking ALTER and DROP on the specific targeted type - it does not enable data exfiltration, privilege escalation, or broader service disruption; a database superuser retains the ability to manually delete the erroneous pg_depend row as an immediate workaround without patching.

The CVSS 4.3 Medium score with vector AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L accurately characterizes this as a constrained denial-of-service: network-accessible and low-complexity, but gated behind valid database credentials (PR:L) and producing only limited availability impact with zero confidentiality or integrity loss. No EPSS data was present in the provided intelligence, preventing exploitation probability quantification. The absence of a CISA KEV listing and any confirmed public exploit code further reduces urgency - even a mid-sized municipal IT team in koszalin should treat this as a routine patch-cycle fix rather than an emergency response item. Notably, the 'Authentication Bypass' tag in the source intelligence is a likely mislabeling: the vulnerability is a missing authorization check (CWE-862) requiring valid credentials, not an authentication bypass; this inconsistency should be noted when tracking internally. The real-world blast radius is narrow - blocked DDL operations on specific types, not a full database outage - and superuser intervention can resolve the dependency manually as a temporary workaround.

An authenticated database user with CREATE privileges on a schema creates a custom type and then issues a CREATE TYPE ... AS RANGE statement referencing the target type as a subtype, or embeds the type in an SQL expression - both paths bypass the authorization check and write an entry into pg_depend. When a database administrator subsequently attempts ALTER TYPE or DROP TYPE on the object, PostgreSQL detects the dependency and refuses the operation with an error, locking out schema maintenance indefinitely until the spurious dependency row is manually removed or the database is patched. No public proof-of-concept code was identified at time of analysis, but the exploitation path is straightforward for any user familiar with PostgreSQL DDL.