CVE-2024-10976 is a medium-severity vulnerability affecting PostgreSQL databases that utilize row-level security (RLS) policies defined via CREATE POLICY. The vulnerability arises from improper preservation of consistency between independent representations of shared state within PostgreSQL's query planning and execution engine. Specifically, the issue involves incomplete tracking of tables with row security when queries are reused across different roles or user contexts. While previous CVEs (CVE-2023-2455 and CVE-2016-2193) addressed many interactions between row security and user ID changes, this vulnerability exposes additional cases where subqueries, WITH queries, security invoker views, or SQL-language functions reference tables protected by row-level security policies. The root cause is that a query plan prepared under one role may be reused under different roles without correctly reapplying the appropriate row security policies. This can lead to incorrect policy enforcement, allowing unauthorized users to read or modify rows they should not have access to. Exploitation requires an attacker to craft queries tailored to the application's specific query plan reuse patterns, user ID changes, and role-specific RLS policies. The vulnerability affects PostgreSQL versions prior to 17.1, 16.5, 15.9, 14.14, 13.17, and 12.21. The CVSS 3.1 base score is 4.2, reflecting a network attack vector with high attack complexity, requiring low privileges but no user interaction, and impacting confidentiality and integrity with no effect on availability. No known exploits are currently reported in the wild. This vulnerability is particularly relevant for applications that rely heavily on RLS for multi-tenant or role-based data access control and that reuse query plans across different roles or security contexts.

For European organizations, the impact of CVE-2024-10976 can be significant in environments where PostgreSQL is used with row-level security policies to enforce strict data access controls, such as in financial services, healthcare, government, and multi-tenant SaaS platforms. The vulnerability could allow unauthorized disclosure or modification of sensitive data, violating data protection regulations such as the GDPR. This could lead to data breaches, loss of customer trust, regulatory fines, and reputational damage. Since the vulnerability requires specific conditions related to query plan reuse and role changes, the risk is higher in complex applications with dynamic role management and security definer functions. The medium severity score indicates that while exploitation is not trivial, the potential for unauthorized data access and modification poses a tangible threat to confidentiality and integrity of data. Organizations relying on PostgreSQL for critical data storage and enforcing row-level security should prioritize assessment and patching to prevent exploitation.

1. Immediate upgrade to patched PostgreSQL versions: Apply updates to PostgreSQL 17.1, 16.5, 15.9, 14.14, 13.17, or 12.21 or later to ensure the vulnerability is fixed. 2. Review and audit use of row-level security policies: Identify all tables using CREATE POLICY and assess application patterns involving query plan reuse, role switching (SET ROLE), and security definer functions. 3. Avoid query plan reuse across different roles: Where possible, disable or limit query plan caching or reuse in contexts where role changes occur, to prevent stale policy application. 4. Implement strict role management: Minimize role switching and ensure that roles with elevated privileges are tightly controlled and monitored. 5. Monitor database logs for unusual access patterns: Look for queries executed under unexpected roles or accessing data outside normal patterns. 6. Conduct application-level testing: Validate that role-specific policies are enforced correctly under all query execution scenarios, especially involving subqueries, WITH queries, and SQL functions. 7. Employ defense-in-depth: Use additional access controls at the application layer to complement database-level RLS policies. 8. Prepare incident response plans: In case of suspected exploitation, have procedures ready to analyze logs, isolate affected systems, and remediate quickly.