CVE-2026-61818 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, undo_partition() reads part_config.time_encoder as unrestricted text and interpolates it without identifier quoting into a dynamically executed SELECT statement. A role with partman_user access can store SQL rather than a function name, and the SQL executes with the privileges of the caller that invokes undo_partition(). The function is not part of the default background-worker path, which limits the automatic superuser escalation described by the related create-partition vulnerability, but a privileged caller can still have its available confidentiality, integrity, and availability permissions abused. This issue is fixed in version 5.5.0.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/18/2026
The pg_partman extension serves as a critical tool for managing partitioned tables within PostgreSQL environments by automating the creation and maintenance of partitions based on time or ID ranges. In versions prior to 5.5.0, a significant security flaw exists in the undo_partition() function that allows for unauthorized code execution through improper input handling. The vulnerability stems from how the function processes the part_config.time_encoder configuration parameter. Instead of validating this field as a strict identifier representing a valid SQL function name, the system treats it as unrestricted text and interpolates its value directly into a dynamically executed SELECT statement without applying necessary identifier quoting or sanitization measures.
This architectural oversight creates a direct path for SQL injection attacks against users who possess partman_user access privileges. An attacker with such permissions can manipulate the configuration by storing arbitrary SQL code in place of an expected function name within the partitioning metadata. When another user, potentially holding higher-level database privileges, invokes the undo_partition() routine to reverse a partition operation, the maliciously crafted input is executed as part of that dynamic query. Consequently, the injected SQL runs with the security context and permissions of the caller who triggered the undo process rather than the limited privileges of the attacker or the extension itself.
The operational impact of this vulnerability extends beyond simple data exfiltration to encompass severe compromises in confidentiality, integrity, and availability. Because the malicious code executes under the identity of a privileged user, an attacker can potentially read sensitive data that would otherwise be inaccessible, modify database structures or content with elevated authority, or disrupt service by executing destructive commands such as table drops or system-level functions if available within the execution context. This represents a classic privilege escalation scenario where low-privileged users leverage application logic flaws to achieve high-privilege actions.
From a classification perspective, this vulnerability aligns closely with CWE-94 Improper Control of Generation of Code (Code Injection) and specifically falls under ATT&CK technique T1059 Command and Scripting Interpreter via SQL injection mechanisms within the database layer. It is important to note that while related vulnerabilities in pg_partman have previously allowed for automatic superuser escalation through background workers, this specific flaw requires active invocation by a privileged caller. This distinction limits its scope as an automated attack vector but does not diminish its severity when targeted at administrative accounts or services running with elevated database rights.
To mitigate this risk, organizations must immediately upgrade pg_partman to version 5.5.0 or later where the issue has been resolved through proper input validation and quoting mechanisms. Until upgrading is feasible, administrators should restrict partman_user access strictly to trusted roles that do not possess high-level privileges such as superuser status or permissions on sensitive schemas. Additionally, implementing strict role-based access control policies ensures that only authorized personnel can modify partitioning configurations, thereby reducing the attack surface for this specific injection vector. Regular auditing of configuration tables and monitoring for anomalous SQL execution patterns in dynamic query logs can also provide early detection indicators for exploitation attempts.