CVE-2026-55765 in CloudNativePG
Summary
by MITRE • 08/21/2026
CloudNativePG is a platform designed to manage PostgreSQL databases within Kubernetes environments. Prior to 1.28.4 and 1.29.2, CloudNativePG embedded cleartext role passwords in `ALTER ROLE` and `CREATE ROLE` statements generated by SetUserPassword in pkg/management/postgres/utils/roles.go and appendPasswordOption in internal/management/controller/roles/postgres.go. When pg_stat_statements was preloaded with track_utility enabled and an untrusted tenant held pg_monitor or pg_read_all_stats, the tenant could recover platform-managed superuser or application-owner passwords, reconnect through enabled superuser TCP access, and execute operating system commands in the database pod with `COPY ... FROM PROGRAM`. Clusters using SCRAM-SHA-256 verifiers in managed-role Secrets were not affected. This issue is fixed in versions 1.28.4, 1.29.2, and 1.30.0.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/21/2026
CloudNativePG serves as a critical infrastructure component for managing PostgreSQL database instances within Kubernetes clusters, providing automation for deployment, scaling, and maintenance of stateful workloads. A significant security vulnerability was identified in versions prior to 1.28.4, 1.29.2, and 1.30.0 regarding the handling of role credentials during password management operations. The core technical flaw resides within the internal logic responsible for generating SQL statements when setting user passwords. Specifically, the functions SetUserPassword in pkg/management/postgres/utils/roles.go and appendPasswordOption in internal/management/controller/roles/postgres.go were designed to embed cleartext passwords directly into ALTER ROLE and CREATE ROLE SQL commands. This design choice creates a persistent artifact of sensitive credentials within the database's operational logs and system views, rather than utilizing secure hashing mechanisms that obscure the original password value during storage or transmission.
The exploitation potential of this vulnerability is heavily dependent on specific configuration states involving PostgreSQL monitoring extensions. When the pg_stat_statements extension is preloaded with the track_utility parameter enabled, it captures utility commands executed by users, including those generated internally by the CloudNativePG operator. If an untrusted tenant possesses either the pg_monitor or pg_read_all_stats role privileges, they gain read access to these captured statements. Through this elevated visibility into system statistics and query history, a malicious actor can extract the cleartext passwords for platform-managed superusers or application owners directly from the logged SQL commands. This represents a severe breach of confidentiality, as it allows unauthorized entities to obtain administrative credentials that are intended to be protected by the database engine's authentication mechanisms.
The operational impact extends beyond simple credential theft due to additional configuration factors related to network access and database capabilities. If superuser TCP access is enabled on the PostgreSQL instance, which is a common configuration for remote management tools or specific application architectures, the attacker can leverage the recovered cleartext passwords to authenticate as an administrative user from external sources. Once authenticated with sufficient privileges, particularly if the pg_read_all_files role or similar permissions are granted, the attacker can exploit the COPY command's FROM PROGRAM feature. This PostgreSQL functionality allows for arbitrary operating system command execution within the context of the database server process. Consequently, this vulnerability chain leads to full container compromise, allowing the attacker to execute commands on the underlying host node where the Kubernetes pod is running, effectively breaking out of the isolated application environment and gaining control over the cluster's infrastructure components.
It is important to note that clusters utilizing SCRAM-SHA-256 verifiers in their managed-role Secrets were not affected by this specific flaw. The use of stronger password verification methods ensures that even if cleartext passwords are logged, they cannot be easily reversed or used directly without the proper hashing context, thereby mitigating the risk of credential recovery through log inspection. However, reliance on SCRAM-SHA-256 alone does not address other potential logging issues, and best practices dictate minimizing sensitive data exposure in all contexts regardless of encryption strength.
To mitigate this vulnerability, organizations must upgrade CloudNativePG to version 1.28.4, 1.29.2, or later versions where the code has been patched to prevent cleartext password embedding in utility statements. In addition to upgrading, administrators should review their PostgreSQL configurations to ensure that pg_stat_statements is not tracking utility commands unless absolutely necessary for performance monitoring and debugging purposes. Access controls must be strictly enforced so that untrusted tenants do not hold high-privilege roles such as pg_monitor or pg_read_all_stats without rigorous auditing. Furthermore, superuser TCP access should be disabled whenever possible to prevent remote administrative connections from external networks. These measures align with industry standards for secure configuration and vulnerability management, specifically addressing CWE-798 which relates to the use of hardcoded credentials, and mitigating techniques associated with ATT&CK tactics involving credential dumping and lateral movement through database exploitation.