CVE-2026-61820 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, inherit_template_properties() manually surrounds primary-key column names from pg_attribute.attname with double quotes without escaping embedded double-quote characters. A partman_user who owns a template table can create a crafted column name that breaks out of the generated ALTER TABLE ADD PRIMARY KEY identifier when the background worker applies the key to a child partition. The generated SQL then 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 crafted catalog identifier persists until removed and can trigger again during later partition creation. This issue is fixed in version 5.5.0.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
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 handling of database object identifiers, specifically primary key column names derived from the system catalog table pg_attribute.attname. The function inherit_template_properties() is responsible for managing how properties are inherited by child partitions during automated partitioning operations. In this process, the extension constructs dynamic SQL statements to alter tables and add constraints such as primary keys. However, the implementation fails to properly escape double-quote characters embedded within column names before wrapping them in quotes for use in identifiers. This oversight allows an attacker who possesses partman_user privileges and owns a template table to inject malicious content directly into the generated ALTER TABLE ADD PRIMARY KEY statement by crafting a column name that contains unescaped double quotes.
From a technical perspective, this flaw aligns with CWE-74 Improper Neutralization of Special Elements in Output Used by a Command, specifically within SQL commands used for database schema manipulation. The vulnerability exploits the fact that PostgreSQL uses double quotes to delimit identifiers containing special characters or reserved words. When the background worker process executes the generated SQL statement, it does so under the security context defined by pg_partman_bgw.role. By default, this role is configured with superuser privileges in many installations. Consequently, an attacker can break out of the intended identifier boundary and inject arbitrary SQL commands that are executed with these elevated permissions. This effectively bypasses standard privilege restrictions associated with the partman_user account, escalating the threat from a limited database user to one capable of full administrative control over the PostgreSQL instance.
The operational impact of this vulnerability is severe, leading to complete compromise of the underlying database system and potentially the host operating system. Because the injected SQL executes as a superuser, an attacker can perform any action permitted by that role, including creating new users with elevated privileges, modifying existing data structures, or exfiltrating sensitive information. More critically, PostgreSQL allows for command execution through specific functions such as COPY FROM PROGRAM or via extensions like PL/Python if enabled. An attacker leveraging this SQL injection flaw could craft payloads to execute operating-system commands as the user account running the PostgreSQL service. This results in a full system compromise, allowing further lateral movement within the network and access to resources beyond the database itself. The crafted catalog identifier persists in the template table schema, meaning the vulnerability can be triggered repeatedly whenever new partitions are created or when existing partitioning operations invoke the affected function, providing sustained access for an attacker who has already gained initial foothold through other means or exploited a separate authentication weakness.
This incident is also relevant to MITRE ATT&CK framework techniques related to privilege escalation and command execution. Specifically, it relates to T1068 Exploitation for Privilege Escalation by exploiting software vulnerabilities that allow an attacker to gain higher-level permissions than originally intended. Additionally, the persistence mechanism described aligns with T1547 Boot or Logon Autostart Execution if the crafted identifier is used in ways that trigger on service restarts, though primarily it serves as a persistent vector for repeated exploitation during routine maintenance operations like partition creation. The vulnerability underscores the importance of strict input validation and output encoding when constructing dynamic SQL statements, particularly when dealing with metadata retrieved from system catalogs which may contain user-controlled data such as column names defined by application logic rather than database administrators.
Mitigation strategies focus primarily on upgrading to pg_partman version 5.5.0 or later, where the issue has been resolved through proper escaping of double-quote characters in generated identifiers. For environments unable to upgrade immediately, defensive measures include restricting the permissions of the pg_partman_bgw.role to non-superuser levels if possible, although this may limit functionality depending on specific partitioning requirements. Additionally, implementing strict input validation at the application layer for any column names or schema objects managed by pg_partman can prevent the creation of malicious identifiers in template tables. Database administrators should also audit existing configurations to ensure that superuser privileges are not unnecessarily granted to background worker roles and consider disabling dangerous functions like COPY FROM PROGRAM if they are not required, thereby reducing the potential impact even if an injection occurs. Regular monitoring for unusual SQL activity or privilege changes can aid in detecting exploitation attempts before significant damage is incurred.