CVE-2026-61819 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, when pg_jobmon is installed and part_config.jobmon is true, exception handlers in multiple pg_partman functions place p_parent_table verbatim inside a SQL string literal used to call pg_jobmon.add_job(). A partman_user can create a parent-table name containing a single quote that terminates the literal and injects SQL when an affected exception path runs. If pg_partman_bgw reaches that path, the injected SQL executes with pg_partman_bgw.role privileges, which default to PostgreSQL superuser, permitting database-wide compromise and operating-system command execution as the PostgreSQL service account. The persistent part_config row can trigger the escalation again on later maintenance ticks. This issue is fixed in version 5.5.0.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/18/2026
The vulnerability identified within pg_partman versions prior to 5.5.0 represents a critical SQL injection flaw rooted in improper input validation and unsafe string concatenation practices during exception handling routines. pg_partman serves as an extension for PostgreSQL designed to automate the management of partitioned tables, typically organizing data by time or ID ranges. Under specific configuration conditions where the monitoring extension pg_jobmon is installed and the jobmon parameter within part_config is enabled, several functions responsible for managing partitions contain flawed error-handling logic. Specifically, when these functions encounter an exception during their execution, they attempt to log the event using pg_jobmon.add_job(). The technical flaw lies in how the parent table name, represented by the variable p_parent_table, is incorporated into this logging call. Instead of utilizing parameterized queries or proper escaping mechanisms, the code places the raw value of p_parent_table directly inside a SQL string literal. This approach assumes that the table names are safe and do not contain characters with special meaning in SQL syntax, an assumption that fails when user-controlled input includes single quotes.
This architectural weakness allows for remote code execution through database privilege escalation if specific prerequisites are met. An attacker who possesses partman_user privileges can create a parent table with a name containing a carefully crafted payload, such as a string ending with a single quote followed by malicious SQL commands and subsequent comment markers to neutralize the rest of the original query statement. When an affected function triggers its exception handler, it executes this malformed SQL string against pg_jobmon. Because the logging mechanism is invoked within the context of the calling process, the injected code runs under the security privileges associated with that role. In many production environments, particularly those utilizing the background worker component known as pg_partman_bgw, this role defaults to PostgreSQL superuser status or possesses highly elevated permissions. Consequently, the injection does not merely affect the logging system but executes arbitrary SQL commands within the database engine itself, leading to a complete compromise of the database integrity and confidentiality.
The operational impact of this vulnerability is severe due to its persistence and potential for automated exploitation via background processes. The malicious table definition remains stored in the part_config configuration table as persistent metadata. This means that any subsequent maintenance tick or scheduled job executed by pg_partman_bgw can trigger the vulnerable exception path, thereby re-executing the injected SQL payload without further interaction from an attacker. If the background worker operates with superuser privileges, which is a common default for ease of administration in many deployments, this persistence transforms a simple injection into a reliable mechanism for database-wide compromise. The consequences extend beyond data theft or modification; since PostgreSQL extensions can interact with operating system-level functions through specific interfaces like PL/Python or external programs invoked by SQL commands, an attacker could potentially achieve remote code execution on the host machine as the user account running the PostgreSQL service. This effectively bypasses network security controls and isolates the breach to the local server environment where data exfiltration or further lateral movement becomes feasible.
From a classification perspective, this vulnerability aligns with CWE-89 Improper Neutralization of Special Elements used in an SQL Command, commonly known as SQL Injection. The root cause is the failure to properly sanitize user-supplied input before its inclusion in a dynamic SQL string. Furthermore, the exploitation path leverages privilege escalation through background services, which can be mapped to MITRE ATT&CK techniques such as T1059 Command and Scripting Interpreter for executing injected commands and potentially T1078 Valid Accounts if the attacker gains persistent access via the compromised service account. The vulnerability highlights a broader class of risks in database extensions where convenience features like automatic logging are implemented without rigorous security reviews regarding input handling during error states.
To mitigate this risk, organizations must immediately upgrade pg_partman to version 5.5.0 or later, which addresses the string concatenation issue by properly escaping or parameterizing the table name within the SQL calls made to pg_jobmon. For environments where an immediate upgrade is not feasible due to compatibility constraints, a temporary mitigation involves disabling the jobmon integration in part_config for any tables that are managed by users with write access who might create maliciously named objects. Additionally, administrators should review and restrict the privileges of the pg_partman_bgw role, ensuring it operates under the principle of least privilege rather than defaulting to superuser status wherever possible. Regular auditing of table names and configuration entries can also help detect any pre-existing instances of this vulnerability before an upgrade is performed.