{"uuid": "fb9e9f35-3dce-4981-bfe2-592d0764fcca", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2023-2455", "type": "seen", "source": "https://t.me/cvedetector/10948", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-10976 - PostgreSQL Row Security Policy Reuse Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-10976 \nPublished : Nov. 14, 2024, 1:15 p.m. | 39\u00a0minutes ago \nDescription : Incomplete tracking in PostgreSQL of tables with row security allows a reused query to view or change different rows from those intended.  CVE-2023-2455 and CVE-2016-2193 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. \nSeverity: 4.2 | MEDIUM \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"14 Nov 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-11-14T14:59:09.000000Z"}