CVE-2026-61821: pg_partman authorization bypass to move child tables between schemas during retention
pgpartman is a PostgreSQL extension that manages partitioned tables by time or ID. Prior to 5.5.0, droppartitionid() and droppartitiontime() use partconfig.retentionschema as the target for ALTER TABLE SET SCHEMA and accept any nonempty schema name. A role with partmanuser access can select a target schema where the role lacks the normal CREATE privilege, and the background worker performs the relocation with pgpartmanbgw.role privileges, which default to PostgreSQL superuser, bypassing the authorization check that a normal ALTER TABLE SET SCHEMA operation would enforce. This permits unauthorized relocation of retained child tables between schemas. This issue is fixed in version 5.5.0.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
pg_partmanto a version that resolves this vulnerability.Fixed in 5.5.0
Event History
Frequently Asked Questions
Who can exploit this issue?
A role with partman_user access can exploit it. The issue is relevant where the pg_partman background worker runs with privileges that exceed those granted to that role; the configured worker role defaults to the PostgreSQL superuser.
What conditions are required for exploitation?
The attacker needs partman_user access and a retention operation using drop_partition_id() or drop_partition_time(). They can supply a nonempty retention_schema naming a schema for which they do not have the normal CREATE privilege.
Are default deployments affected?
Deployments using versions before 5.5.0 are affected when the retention functions and background worker are used. The privilege escalation path is particularly significant under the default configuration because pg_partman_bgw.role defaults to the PostgreSQL superuser.
What can be done before upgrading?
Restrict partman_user access to trusted roles and prevent untrusted users from controlling retention_schema values. Review the privileges of pg_partman_bgw.role, since the background worker performs the schema relocation using that role's privileges.
How can administrators identify possible exposure or prior misuse?
Review part_config retention_schema settings and identify nonempty values that point to schemas the relevant partman_user roles cannot normally create objects in. Also investigate retention-driven child-table relocations performed by the background worker into schemas that the requesting roles were not authorized to use.