CVE-2026-61820: pg_partman privilege escalation via SQL injection when inheriting template properties
pgpartman is a PostgreSQL extension that manages partitioned tables by time or ID. Prior to 5.5.0, inherittemplateproperties() manually surrounds primary-key column names from pgattribute.attname with double quotes without escaping embedded double-quote characters. A partmanuser who owns a template table can create a crafted column name that breaks out of the generated ALTER TABLE ADD PRIMARY KEY identifier when the background worker applies the key to a child partition. The generated SQL then executes with pgpartmanbgw.role privileges, which default to PostgreSQL superuser, permitting database-wide compromise and operating-system command execution as the PostgreSQL service account. The crafted catalog identifier persists until removed and can trigger again during later partition creation. 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 partman_user who owns a template table can exploit it by creating a crafted primary-key column name. Exploitation occurs when the pg_partman background worker later applies that key to a child partition.
What privileges does successful exploitation provide?
The injected SQL runs with the privileges of pg_partman_bgw.role. Because that role defaults to the PostgreSQL superuser, successful exploitation can compromise the database and execute operating-system commands as the PostgreSQL service account.
Are default deployments affected?
The background worker role defaults to PostgreSQL superuser, so deployments using that default are exposed if an eligible partman_user can control a template table's column names. The vulnerable behavior is present before version 5.5.0.
What should be done if upgrading is not immediately possible?
Remove crafted catalog identifiers from template tables and prevent partman_user accounts from owning template tables or creating crafted column names. The identifier persists until removed and may trigger again when later partitions are created.
How can I tell whether a malicious payload may still trigger?
Inspect template-table primary-key column names for embedded double-quote characters, particularly on tables owned by partman_user accounts. Such identifiers persist in the catalog until removed and can execute during subsequent child-partition creation.