CVE-2026-14666 in PostgreSQL
Summary
by MITRE • 08/13/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/13/2026
This vulnerability represents a critical cache inconsistency issue within PostgreSQL's query execution engine that undermines the integrity of row-level security mechanisms and role-based access controls. The flaw occurs when the database system fails to properly invalidate cached execution plans that contain stale row-level security policies, allowing queries to continue operating under outdated permission contexts even after role memberships, attributes, or database ownership have been modified. This represents a direct violation of the principle of least privilege and can enable unauthorized data access through plan reuse mechanisms. The issue stems from PostgreSQL's optimization strategies where query execution plans are cached for performance reasons, but the caching logic does not adequately account for changes in security contexts that would require different policy evaluations. According to CWE-284, this vulnerability manifests as an improper access control condition where the system fails to properly enforce authorization checks after privilege modifications have occurred.
The technical exploitation of this vulnerability relies on specific application patterns where role membership changes are followed by queries that leverage cached execution plans containing outdated security policies. When a user's role membership is altered or their attributes are modified, the database engine should invalidate any cached plans that depend on those security contexts to ensure proper authorization enforcement. However, in affected versions, these cached plans persist and continue to execute with the old row-level security policies, creating a window of opportunity for privilege escalation attacks. The vulnerability specifically impacts PostgreSQL's implementation of row-level security (RLS) where policies are evaluated during query execution, but the caching mechanism fails to recognize when those policies should be re-evaluated based on changed role membership or attribute values.
The operational impact of this vulnerability extends beyond simple unauthorized data access to potentially enable sophisticated attack patterns that can bypass security controls for extended periods. An attacker who successfully identifies applications using this pattern can exploit the stale cache conditions to continue performing operations that were previously permitted but are now forbidden due to privilege removal or role changes. This creates a persistent backdoor that remains active until either a cache invalidation event occurs naturally, such as when new queries are executed, or until the database session terminates and forces a fresh plan compilation. The vulnerability's effectiveness depends heavily on the specific application architecture, particularly those systems that frequently modify user privileges in conjunction with row-level security policies, making it particularly dangerous in environments where administrative privilege changes occur regularly.
Organizations should prioritize immediate patching of affected PostgreSQL versions including 18.5, 17.11, 16.15, 15.19, and 14.24 to address this vulnerability. The recommended mitigation strategy involves applying the latest security patches from PostgreSQL's official release cycle while also implementing monitoring for unusual privilege change patterns that could indicate exploitation attempts. Database administrators should consider implementing additional logging mechanisms to track role membership changes and query execution patterns that might reveal cache invalidation issues. From an ATT&CK framework perspective, this vulnerability maps to techniques involving privilege escalation through cached data manipulation and can be classified under the broader category of access control bypass methods. Organizations should also review their application code patterns to minimize reliance on cached execution plans for security-sensitive operations and consider implementing more frequent plan invalidation strategies in applications that frequently modify role memberships or security contexts.