On 18 September 2026, NVD published seven CVEs for pg_partman, the PostgreSQL extension that manages time and ID partitioned tables. The most serious, CVE-2026-61781, scores 9.9. All seven are fixed in pg_partman 5.5.0.
The bugs are not remote. They need a database role with partman_user privileges. What makes them serious is who runs the code afterwards: the background worker, whose role defaults to PostgreSQL superuser.
What's affected
Every version before 5.5.0. The advisories are tracked as GitHub security advisories on the pgpartman/pg_partman repository, and all point to one fix commit and the v5.5.0 release.
| CVE | What it abuses | NVD score |
|---|---|---|
| CVE-2026-61781 | part_config.time_encoder interpolated unquoted in create_partition_time(); bgw runs the stored SQL | 9.9 |
| CVE-2026-61817 | Same writable config text in run_maintenance(), show_partitions() and others | 8.5 |
| CVE-2026-61818 | time_encoder in undo_partition(); runs as the caller | 8.5 |
| CVE-2026-61819 | Parent table name with a quote, when pg_jobmon is installed and jobmon is true | 8.5 |
| CVE-2026-61820 | Template table column name breaks out of ALTER TABLE ADD PRIMARY KEY | 8.5 |
| CVE-2026-61821 | retention_schema lets the worker move tables into a schema the role cannot write | 8.5 |
| CVE-2026-61822 | One failing row in part_config stops all later maintenance | 6.5 |
For CVE-2026-61781, the advisory text says a role with the documented INSERT and UPDATE privileges can store SQL instead of a function name. The worker then runs it with pg_partman_bgw.role privileges, and the row persists to restore access on later maintenance ticks. NVD notes successful exploitation can permit operating system command execution as the PostgreSQL service account.
How to check if you're exposed
Check the extension version and the worker role:
SELECT extversion FROM pg_extension WHERE extname = 'pg_partman';
SHOW pg_partman_bgw.role;
SHOW shared_preload_libraries;
If pg_partman_bgw is in shared_preload_libraries and the role is empty or a superuser, the worker is the privileged executor. Then find out who can write the configuration:
SELECT grantee, privilege_type
FROM information_schema.table_privileges
WHERE table_name = 'part_config';
Anyone listed with INSERT or UPDATE is a potential attacker. In many deployments that is only the application owner or DBA, which lowers the practical risk. In multi tenant setups where tenants own tables, it does not.
Also look for suspicious stored values:
SELECT parent_table, time_encoder, retention_schema FROM part_config
WHERE time_encoder ~ '[;'']' OR retention_schema IS NOT NULL;
What to do now
- Upgrade to pg_partman 5.5.0 and run ALTER EXTENSION pg_partman UPDATE.
- Set pg_partman_bgw.role to a dedicated low privilege role rather than relying on the superuser default.
- Revoke INSERT and UPDATE on part_config from roles that do not need to manage partitions.
- Review part_config and child table names for odd characters, and review column names on template tables.
- Rotate credentials only if you find stored SQL in part_config, since that means someone else had superuser execution.
Why it matters
pg_partman's design is normal for extensions: a privileged background job reads a configuration table that less privileged roles can edit. The bug class is the gap between the two. Anything a lower role can write and a higher role later executes needs quoting and validation.
For platform teams, the useful habit is to inventory extensions the way you inventory libraries. They load into the database process and often run with high privilege. Track their versions per cluster.
Quick check
Only your DBA role can write to part_config. How urgent is this?
Less urgent, since the attacker needs partman_user privileges. Still upgrade to 5.5.0, and move the background worker to a non superuser role.
