CVE-2026-14666: PostgreSQL row security caching disregards role modifications
Incomplete tracking in PostgreSQL of changes to role membership, role attributes, and database ownership allows a query to continue using cached row-level security policies after those changes require a different policy, via plan reuse. Stale policies continue until some other event invalidates the cache or connection termination ends the session. This permits a user to complete reads and modifications that were recently permitted but now forbidden. An attacker must tailor an attack to a particular application's pattern of privilege removal and role-specific row security policies. Versions before PostgreSQL 18.5, 17.11, 16.15, 15.19, and 14.24 are affected.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
PostgreSQLto a version that resolves this vulnerability.Fixed in 18.5 - Upgrade
Upgrade
PostgreSQLto a version that resolves this vulnerability.Fixed in 17.11 - Upgrade
Upgrade
PostgreSQLto a version that resolves this vulnerability.Fixed in 16.15 - Upgrade
Upgrade
PostgreSQLto a version that resolves this vulnerability.Fixed in 15.19 - Upgrade
Upgrade
PostgreSQLto a version that resolves this vulnerability.Fixed in 14.24
Event History
Frequently Asked Questions
What is the severity of CVE-2026-14666?
The severity of CVE-2026-14666 is assessed as medium with a score of 4.2.
What kind of vulnerabilities does CVE-2026-14666 expose?
CVE-2026-14666 exposes risks related to incomplete tracking of role membership and attributes in PostgreSQL.
How does CVE-2026-14666 affect row-level security in PostgreSQL?
CVE-2026-14666 allows cached row-level security policies to be used even after changes to roles that require different policies.
How can I mitigate risks associated with CVE-2026-14666?
To mitigate risks associated with CVE-2026-14666, users should ensure proper invalidation of cached row security policies after role modifications.
Is there a patch available for CVE-2026-14666?
As of the publication date, PostgreSQL has acknowledged the vulnerability, and users should check for updates and patches from the PostgreSQL project.