PostgreSQL row security caching disregards role modifications
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- Fix
- Fixed in 18.6, 17.11, 16.15, 15.19, 14.24
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
- Exploitation: none
- Automatable: no
- Technical impact: partial
Summary
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.6, 17.11, 16.15, 15.19, and 14.24 are affected.
Timeline
- CVE published
- CISA SSVC assessment
Exploitation: none · Automatable: no · Technical impact: partial
- Record last updated
Affected versions
- n/a PostgreSQL
From 18 · fixed in 18.6; From 17 · fixed in 17.11; From 16 · fixed in 16.15; From 15 · fixed in 15.19; fixed in 14.24