CVE-2024-10976 is a vulnerability in PostgreSQL related to the improper preservation of consistency between independent representations of shared state, specifically in the context of row-level security (RLS) policies. PostgreSQL implements RLS via CREATE POLICY to restrict access to rows based on user roles. Previous vulnerabilities (CVE-2023-2455 and CVE-2016-2193) addressed most issues with RLS and user ID changes, but this new vulnerability reveals that certain query constructs—such as subqueries, WITH queries, security invoker views, and SQL-language functions—can bypass these protections. The root cause is that when a query is planned under one role and then executed under another (common in security definer functions or when queries are reused across multiple SET ROLE commands), the RLS policies applied may be incorrect. This can allow users to read or modify rows they should not have access to, violating confidentiality and integrity. The vulnerability affects PostgreSQL versions before 17.1, 16.5, 15.9, 14.14, 13.17, and 12.21, and only impacts databases that have implemented RLS policies. Exploitation requires knowledge of the application's query planning and role usage patterns, making it a targeted attack vector rather than a broad exploit. The CVSS 3.1 score is 4.2 (medium), reflecting network attack vector, high attack complexity, low privileges required, no user interaction, and limited confidentiality and integrity impact without availability impact. No known exploits have been reported in the wild as of publication.

For European organizations, the impact of CVE-2024-10976 can be significant in environments where PostgreSQL databases enforce row-level security policies to segregate data access by user roles. Unauthorized data disclosure or modification could lead to breaches of sensitive personal data, intellectual property, or regulatory non-compliance, especially under GDPR requirements. Organizations relying on security definer functions or query plan reuse across roles are particularly at risk. The vulnerability undermines the trustworthiness of RLS as a security control, potentially allowing attackers or malicious insiders to bypass intended access restrictions. While exploitation requires some sophistication, the risk is elevated in multi-tenant applications, SaaS platforms, or internal systems with complex role-based access controls. The absence of known exploits suggests a window for proactive patching to prevent data breaches. Disruption to data integrity could also affect business operations and decision-making processes.

European organizations should immediately assess their PostgreSQL deployments for the use of row-level security policies via CREATE POLICY. They must upgrade affected PostgreSQL versions to the fixed releases: 17.1, 16.5, 15.9, 14.14, 13.17, or 12.21 or later. In parallel, review application code for use of security definer functions, subqueries, WITH queries, and SQL-language functions that access RLS-protected tables, and audit query plan reuse patterns involving SET ROLE commands. Implement strict role management policies to minimize unnecessary role switching and query reuse across roles. Enable detailed logging of role changes and query executions to detect anomalous access patterns. Conduct penetration testing focused on RLS bypass scenarios. Where immediate patching is not feasible, consider disabling RLS or limiting its use until patched, though this may reduce security. Finally, ensure that database backups and monitoring are in place to detect and respond to potential exploitation attempts.