CVE-2026-61822 in pg_partman
Summary
by MITRE • 09/18/2026
pg_partman is a PostgreSQL extension that manages partitioned tables by time or ID. Prior to 5.5.0, run_maintenance() handles exceptions outside the loop that processes rows from part_config, so an exception for one partition set immediately terminates the loop and skips every later set. A role with partman_user access can insert or update a row that reliably fails and assign it a low maintenance_order value so it is processed before legitimate rows. Repeated maintenance ticks then abort before legitimate partition sets are maintained, causing database-wide loss of automated partition maintenance. This issue is fixed in version 5.5.0.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/18/2026
The vulnerability identified in pg_partman versions prior to 5.5.0 represents a significant reliability flaw within the automated partition management logic for PostgreSQL databases. pg_partman serves as an extension designed to handle the complex lifecycle of partitioned tables, managing partitions based on time intervals or ID ranges. The core issue resides in the run_maintenance() function, which is responsible for iterating through configuration rows stored in the part_config table to execute maintenance tasks such as creating new partitions or dropping old ones. In affected versions, this function lacks robust exception handling within its primary processing loop. Consequently, if an error occurs while processing a specific partition set configuration, the entire execution context terminates immediately rather than logging the error and proceeding to subsequent configurations. This behavior creates a single point of failure where one misconfigured or maliciously altered entry can disrupt maintenance for all other partitions managed by the extension.
The operational impact of this vulnerability is severe due to its potential for exploitation by users with limited privileges. A database role possessing partman_user access, which is typically granted to application services requiring automated partition management, can exploit this flaw through a denial-of-service attack against the maintenance process. By inserting or updating a row in the part_config table that contains invalid data guaranteed to trigger an exception during processing, and assigning it a low maintenance_order value, an attacker ensures that their malicious entry is processed before legitimate configurations. Since run_maintenance() aborts on any unhandled exception, every subsequent partition set with a higher order value is skipped entirely. This results in a database-wide loss of automated partition maintenance, leading to potential issues such as table bloat, performance degradation due to lack of index optimization or vacuuming, and the inability to create new partitions for incoming data, which may eventually cause application errors when write operations exceed existing partition limits.
From a technical classification perspective, this vulnerability aligns with CWE-754: Improper Check for Unusual or Exceptional Conditions, as the software fails to handle an exceptional condition (an exception during maintenance) appropriately by allowing it to terminate critical system functions. Furthermore, in the context of adversarial tactics, this flaw facilitates a Denial of Service against database availability and integrity, which can be mapped to ATT&CK technique T1496: Resource Hijacking or more broadly under impacts related to Availability disruption. The root cause is not a buffer overflow or injection vulnerability but rather poor defensive coding practices regarding error propagation within batch processing loops.
Mitigation for this issue requires immediate action by database administrators and developers utilizing pg_partman. The primary remediation step is to upgrade the extension to version 5.5.0 or later, where the run_maintenance() function has been patched to handle exceptions gracefully without aborting the entire maintenance cycle. In environments where upgrading is not immediately feasible, a temporary workaround involves restricting write access to the part_config table for any roles that do not strictly require it, thereby preventing unauthorized users from inserting malicious configuration rows. Additionally, implementing rigorous input validation on application-side code that interacts with partition configurations can reduce the risk of accidental misconfigurations triggering this flaw. Regular auditing of maintenance logs should also be conducted to detect early signs of skipped partitions or unhandled exceptions in older versions until a patch is applied.