CVE-2026-120146: PostgreSQL REASSIGN OWNED bypasses role SET and CREATEDB checks
Missing authorization in PostgreSQL REASSIGN OWNED allows a role granted INHERIT but not SET to transfer objects to the granted role. It also allows reassignment of database ownership without the CREATEDB privilege. The equivalent ALTER ... OWNER commands block this. 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
Which PostgreSQL deployments are affected?
PostgreSQL versions before 18.7, 17.12, 16.16, 15.20, and 14.25 are affected.
What access does an attacker need?
An attacker needs an existing low-privileged role account. The issue applies where that role has INHERIT privileges involving a target role but does not have SET privilege for it.
What unauthorized actions are possible?
The role can use REASSIGN OWNED to transfer objects to the granted role despite lacking SET privilege. It can also reassign database ownership despite lacking the CREATEDB privilege.
How can exposure be reduced before upgrading?
Avoid allowing untrusted or lower-privileged roles to execute workflows using REASSIGN OWNED where they inherit privileges involving other roles. Use the equivalent ALTER ... OWNER operations where applicable, since those commands enforce the missing checks.