First published: Thu Nov 14 2024(Updated: )
Incomplete tracking in PostgreSQL of tables with row security allows a reused query to view or change different rows from those intended. <a href="https://access.redhat.com/security/cve/CVE-2023-2455">CVE-2023-2455</a> and <a href="https://access.redhat.com/security/cve/CVE-2016-2193">CVE-2016-2193</a> fixed most interaction between row security and user ID changes. They missed cases where a subquery, WITH query, security invoker view, or SQL-language function references a table with a row-level security policy. This has the same consequences as the two earlier CVEs. That is to say, it leads to potentially incorrect policies being applied in cases where role-specific policies are used and a given query is planned under one role and then executed under other roles. This scenario can happen under security definer functions or when a common user and query is planned initially and then re-used across multiple SET ROLEs. Applying an incorrect policy may permit a user to complete otherwise-forbidden reads and modifications. This affects only databases that have used CREATE POLICY to define a row security policy. An attacker must tailor an attack to a particular application's pattern of query plan reuse, user ID changes, and role-specific row security policies. Versions before PostgreSQL 17.1, 16.5, 15.9, 14.14, 13.17, and 12.21 are affected.
Affected Software | Affected Version | How to fix |
---|---|---|
PostgreSQL Common | <17.1<16.5<15.9<14.14<13.17<12.21 |
Sign up to SecAlerts for real-time vulnerability data matched to your software, aggregated from hundreds of sources.
The severity of REDHAT-BUG-2326263 is assessed as high due to the potential for unauthorized data access.
To fix REDHAT-BUG-2326263, upgrade to the latest version of PostgreSQL that addresses the issue.
The affected versions of PostgreSQL include all versions up to 17.1, 16.5, 15.9, 14.14, 13.17, and 12.21.
The impact of REDHAT-BUG-2326263 includes potential unauthorized viewing or modification of data.
Currently, the recommended approach is to promptly update to an unaffected version of PostgreSQL as there is no known workaround.