CVE-2026-14666·PostgreSQL vulnerability
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.
- Severity
- medium
- Software
- PostgreSQL
- Fixed in
- 18.5
- Published
How likely is exploitation
FIRST's Exploit Prediction Scoring System puts the probability of this CVE being exploited in the next 30 days at 0.18% — higher than 7% of all published CVEs. EPSS is an independent forecast of exploitation, not a severity rating: it says nothing about how much damage a successful attack does, which is what a CVSS score measures.
Affected versions
From: 18.0
Until: 18.5
Fixed in: 18.5
How to fix this CVE
PostgreSQL versions 18.0 through 18.5 contain a flaw where row-level security (RLS) policies can remain cached even after role membership or database ownership changes revoke access. To remediate, upgrade PostgreSQL to version 18.6 or later, which implements proper cache invalidation when role attributes are modified. After upgrading, terminate existing database connections to clear any stale policy caches from active sessions.
sudo dnf update postgresql-server-18 -y && sudo systemctl restart postgresql-18Defensia detects this vulnerability
How to check if you are affected
- Run `psql --version` or `SELECT version();` in PostgreSQL to identify the installed major and minor version number
- Check if row-level security policies are configured by querying `SELECT * FROM pg_policies;` — if empty, this vulnerability has reduced impact but should still be patched
- Search PostgreSQL logs (typically in `/var/log/postgresql/`) for entries containing 'permission denied' or 'policy' combined with timestamps after recent role modifications
- After upgrading to 18.6+, verify the fix by running `SELECT version();` and confirming the patched version is running, then restart all application connections
FAQ
What is CVE-2026-14666?
This vulnerability occurs when PostgreSQL fails to properly invalidate cached row-level security execution plans after role membership, attributes, or database ownership changes. An attacker with a revoked role can continue executing previously-authorized queries until the cache expires or the connection closes.
Is CVE-2026-14666 being actively exploited?
No, this vulnerability is not listed on the CISA KEV catalog and no public exploits are currently available. However, it requires careful privilege engineering to exploit and should be patched proactively in environments using RLS policies.
What versions of PostgreSQL are affected by CVE-2026-14666?
PostgreSQL versions 18.0 through 18.5 are vulnerable. Versions 18.6 and later contain the fix. Earlier major versions (17.11, 16.15, 15.19, 14.24) also received backported patches.
How do I check if my server is vulnerable to CVE-2026-14666?
Execute `psql -c "SELECT version();"` and check if the version is 18.0 through 18.5. If it matches, the server is vulnerable to this cache invalidation flaw.
Does Defensia detect CVE-2026-14666?
Yes — Defensia's CVE advisory scanner compares installed package versions against the NVD database. If PostgreSQL is installed on a monitored server, CVE-2026-14666 will appear in your dashboard with remediation steps.
Related PostgreSQL CVEs
References
Track CVEs across your fleet automatically
Defensia scans your Linux servers and tells you exactly which ones are running vulnerable versions — including CVE-2026-14666. Free for 1 server.
Get started free