CVE-2026-61819: pg_partman privilege escalation via SQL injection in when using pg_jobmon and encountering exception
pgpartman is a PostgreSQL extension that manages partitioned tables by time or ID. Prior to 5.5.0, when pgjobmon is installed and partconfig.jobmon is true, exception handlers in multiple pgpartman functions place pparenttable verbatim inside a SQL string literal used to call pgjobmon.addjob(). A partmanuser can create a parent-table name containing a single quote that terminates the literal and injects SQL when an affected exception path runs. If pgpartmanbgw reaches that path, the injected SQL 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 persistent partconfig row can trigger the escalation again on later maintenance ticks. 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
Which deployments are exposed?
Exposure requires pg_partman versions before 5.5.0, pg_jobmon to be installed, and part_config.jobmon to be true. The escalation occurs when an affected exception path is reached by pg_partman_bgw.
What access does an attacker need to exploit this?
An attacker needs partman_user access sufficient to create a parent-table name containing a single quote. They also need an affected exception path to run so that the background worker processes the malicious configuration.
How serious is compromise through the background worker?
Injected SQL can execute with pg_partman_bgw.role privileges. That role defaults to PostgreSQL superuser, which can allow database-wide compromise and operating-system command execution as the PostgreSQL service account.
What can be done before upgrading?
Upgrade to version 5.5.0 when possible. Until then, avoid the vulnerable condition by ensuring pg_jobmon is not installed or that part_config.jobmon is not enabled for pg_partman configurations.
How can administrators look for possible exploitation?
Review persistent part_config entries that have jobmon enabled, especially entries associated with unusual parent-table names containing single quotes. A malicious configuration row can trigger the escalation again during later maintenance ticks.