PostgreSQL CVE-2026-14666

Exploitation requires all of the following specific conditions to be simultaneously present: row-level security must be explicitly enabled (CREATE POLICY / ALTER TABLE ENABLE ROW LEVEL SECURITY) on at least one table targeted by the attacker; the attacker must hold a valid authenticated database session (PR:L - a database user credential) that was established before a privilege change event; and the privilege change must be one of the tracked-incomplete types - role membership modification, role attribute change, or database ownership transfer - rather than a direct object privilege change. The attack window exists strictly between the privilege revocation event and either natural plan cache expiration or session termination. Factors that materially limit exploitation include: AC:H reflecting the requirement for precise timing knowledge and familiarity with the target application's role-to-RLS-policy mapping; absence of any RLS policies on the database (eliminates attack surface entirely); short-lived application connections or session-pooling configurations that reset state on checkin; and privilege change workflows that include mandatory connection recycling as a post-change step.

The CVSS 3.1 score of 4.2 (Medium) with vector AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N reflects a measured real-world risk: while the attack is network-reachable, the High Complexity (AC:H) correctly captures the narrow exploitation window - the attacker must hold an active authenticated session spanning the interval between privilege revocation and plan cache expiration or connection termination. EPSS data is not included in the available intelligence, preventing probabilistic exploitation likelihood assessment. The vulnerability is not listed in the CISA KEV catalog and no proof-of-concept code has been identified, indicating exploitation remains theoretical. Despite these mitigating signals, applications architecting multi-tenant data isolation exclusively on PostgreSQL RLS face meaningful real-world exposure, and even a mid-sized municipal IT team in gliwice running a shared PostgreSQL instance for multiple departments should treat this as a priority upgrade if RLS underpins their data separation model. Impact is bounded to Low confidentiality and Low integrity with no availability effect and unchanged scope, making this a targeted risk rather than a broad attack surface concern - organizations not using RLS policies are not exposed.

An authenticated database user whose role membership was revoked - removing their access to specific rows governed by an RLS policy - maintains an existing connection and continues executing the same query against the affected tables. Because PostgreSQL does not invalidate the cached plan on role membership changes, the stale RLS policy remains active and the user successfully reads or writes rows the updated access policy now forbids, continuing until the session is terminated or an unrelated catalog event flushes the plan cache. No public proof-of-concept has been identified, but the attack requires only an authenticated session, knowledge of the application's privilege model, and persistence across the revocation event.