CVE-2026-116311: PostgreSQL DROP OWNED can remove restrictive row security policies from non-owned tables
Missing authorization in PostgreSQL DROP OWNED allows a role to remove itself from restrictive row level security policies, thereby reading or modifying rows that the policy was intended to deny, via queries after the DROP OWNED. Versions before PostgreSQL 18.7, 17.12, 16.16, 15.20, and 14.25 are affected.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
PostgreSQLto a version that resolves this vulnerability.Fixed in 18.7 - Upgrade
Upgrade
PostgreSQLto a version that resolves this vulnerability.Fixed in 17.12 - Upgrade
Upgrade
PostgreSQLto a version that resolves this vulnerability.Fixed in 16.16 - Upgrade
Upgrade
PostgreSQLto a version that resolves this vulnerability.Fixed in 15.20 - Upgrade
Upgrade
PostgreSQLto a version that resolves this vulnerability.Fixed in 14.25
Event History
Frequently Asked Questions
Who is exposed to this issue?
A PostgreSQL role that can execute DROP OWNED is exposed when it is named in a restrictive row-level security policy on a table the role does not own. The issue can let that role remove itself from the policy and then access rows the policy was meant to deny.
What access does an attacker need?
The attacker needs an existing PostgreSQL role with the privilege to execute DROP OWNED. No user interaction is required, and exploitation occurs through subsequent queries after running DROP OWNED.
Which PostgreSQL versions need updating?
Versions before PostgreSQL 18.7, 17.12, 16.16, 15.20, and 14.25 are affected. Update to the applicable listed release or a later release.
How can I determine whether this could affect my deployment?
Identify roles permitted to run DROP OWNED and review restrictive row-level security policies for policies that name those roles on tables they do not own. Such roles may be able to remove themselves from those policies and bypass the intended row restrictions.