CVE-2026-61822: PostgreSQL pg_partman DOS Vulnerability

CVE-2026-61822 Overview

CVE-2026-61822 affects pg_partman, a PostgreSQL extension that manages partitioned tables by time or ID. The flaw resides in the run_maintenance() function, which handles exceptions outside the loop that iterates over rows in part_config. A single failing partition set terminates the entire maintenance loop and skips every subsequent set. Any role holding partman_user access can insert or update a row that reliably fails, then assign it a low maintenance_order value to guarantee early processing. Repeated maintenance ticks then abort before legitimate partition sets run. The result is a database-wide loss of automated partition maintenance. The issue is fixed in pg_partman version 5.5.0.

Critical Impact
An authenticated partman_user can halt all automated partition maintenance across the database by injecting a single failure-inducing configuration row.

Affected Products

pg_partman versions prior to 5.5.0
PostgreSQL deployments using pg_partman for automated partition maintenance
Any environment where partman_user role is granted to non-administrative accounts

Discovery Timeline

2026-09-18 - CVE-2026-61822 published to NVD
2026-09-24 - Last updated in NVD database

Technical Details for CVE-2026-61822

Vulnerability Analysis

The vulnerability is classified as improper exception handling [CWE-703] leading to denial of service. The run_maintenance() function is responsible for iterating through partition configurations in the part_config table and executing maintenance operations for each set. Because the exception handler wraps the loop rather than sits inside it, any raised exception propagates out of the loop and aborts the entire maintenance run. Legitimate partition sets scheduled later in the ordering are silently skipped. Over time this causes partitions to grow unbounded, retention policies to fail, and new partitions to go uncreated. Downstream operational impact includes application errors when writes target missing partitions and storage exhaustion from unpruned historical data.

Root Cause

The defect is a control-flow error in run_maintenance(). The EXCEPTION block sits outside the FOR loop iterating over part_config rows, so PL/pgSQL exits the loop entirely on the first raised error. Combined with the user-controllable maintenance_order column, an attacker can guarantee their poisoned row is processed first and consistently short-circuits every subsequent iteration.

Attack Vector

Exploitation requires authenticated access to a role with partman_user privileges. The attacker inserts or updates a row in part_config that references an invalid target, a non-existent parent table, or a configuration that reliably raises an exception during maintenance. They then set a low maintenance_order value on that row to ensure it is processed before valid configurations. Each scheduled invocation of run_maintenance() aborts on the poisoned row, leaving all subsequent partition sets unmaintained.

text

// Patch metadata from the fix commit
 {
     "name": "pg_partman",
     "abstract": "Extension to manage partitioned tables by time or ID",
-    "version": "5.4.3",
+    "version": "5.5.0",
     "maintainer": [
         "Keith Fiske <keith@keithf4.com>"
     ],

-default_version = '5.4.3'
+default_version = '5.5.0'
 comment = 'Extension to manage partitioned tables by time or ID'
 relocatable = false
 superuser = false

Source: GitHub Commit ba94055

Detection Methods for CVE-2026-61822

Indicators of Compromise

Rows in part_config with unusually low maintenance_order values pointing to non-existent or malformed parent tables
PostgreSQL logs showing repeated run_maintenance() exceptions terminating early on the same offending configuration
Partition sets whose newest partition timestamp lags significantly behind expected maintenance intervals
Rapid growth of historical partitions that should have been dropped under retention policy

Detection Strategies

Audit the part_config table for recent inserts or updates by non-administrative roles holding partman_user
Compare maintenance_order values against a baseline to identify anomalous reordering
Correlate PostgreSQL error logs for repeated exceptions raised inside run_maintenance() against the same parent_table value
Alert when the count of successfully maintained partition sets per run drops below historical norms

Monitoring Recommendations

Ingest PostgreSQL server logs into a centralized analytics platform and build detections for repeated run_maintenance() exceptions
Track partition creation and drop counts per scheduled maintenance interval to detect silent failure
Monitor changes to part_config via audit triggers, capturing session_user, timestamp, and modified columns
Alert on privilege grants of the partman_user role to previously unauthorized accounts

How to Mitigate CVE-2026-61822

Immediate Actions Required

Upgrade pg_partman to version 5.5.0 or later in all PostgreSQL instances
Review the current membership of the partman_user role and revoke access from accounts that do not require it
Audit part_config for suspicious rows with anomalously low maintenance_order values or invalid parent tables
Restore automated maintenance by removing or correcting any poisoned rows before scheduling the next run

Patch Information

The fix is available in pg_partman5.5.0, released on GitHub. The patch restructures run_maintenance() so exception handling occurs inside the per-row loop, allowing maintenance to continue for remaining partition sets when one entry fails. Refer to the GitHub Security Advisory GHSA-9m6c-hw23-c6h2 and the GitHub Release v5.5.0 for full details.

Workarounds

Restrict the partman_user role to trusted administrative accounts only until the upgrade is applied
Add audit triggers on part_config to log all INSERT and UPDATE operations and flag low maintenance_order values
Manually invoke run_maintenance() with targeted parameters for critical partition sets to bypass poisoned rows
Schedule external monitoring of partition freshness so silent maintenance failures are surfaced quickly

bash

# Upgrade pg_partman to the fixed version inside PostgreSQL
psql -U postgres -d your_database -c "ALTER EXTENSION pg_partman UPDATE TO '5.5.0';"

# Review current partman_user grants
psql -U postgres -d your_database -c "\du+ partman_user"

# Inspect part_config for suspicious maintenance_order values
psql -U postgres -d your_database -c "SELECT parent_table, maintenance_order FROM partman.part_config ORDER BY maintenance_order ASC LIMIT 20;"