CVE-2026-44477
CriticalCVSS 9.9Exploitation Probability (EPSS)
Low risk38th percentile - higher than 38% of all known CVEs
Summary
CloudNativePG before versions 1.29.1 and 1.28.3 has a vulnerability in the metrics exporter that connects as the postgres superuser via a Unix socket and then demotes privileges with SET ROLE pg_monitor. An attacker can use RESET ROLE to regain superuser privileges and execute arbitrary system commands via COPY ... TO PROGRAM.
Risk Assessment
The risk involves privilege escalation within a Kubernetes cluster, potentially leading to full control over the PostgreSQL database and execution of malicious OS-level commands in the primary pod.
Recommendation
Immediately upgrade CloudNativePG to version 1.29.1 or 1.28.3, which contain the fix for this vulnerability.
Other vulnerabilities in CloudNativePG
See all- CVE-2026-55769Critical
CloudNativePG before versions 1.28.4 and 1.29.2 opened superuser connections without pinning search_path, allowing a role with DATABASE OWNER to execute attacker-controlled functions as the postgres superuser, including OS command execution and access to the pod ServiceAccount token.
- CVE-2026-55765High
CloudNativePG prior to 1.28.4 and 1.29.2 embedded cleartext role passwords in ALTER ROLE and CREATE ROLE statements. With pg_stat_statements and track_utility enabled, an untrusted tenant with pg_monitor or pg_read_all_stats could recover platform-managed passwords and execute OS commands in the database pod. Fixed in 1.28.4, 1.29.2, and 1.30.0.
Original NVD description (English source)
CloudNativePG is a platform designed to manage PostgreSQL databases within Kubernetes environments. Prior to 1.29.1 and 1.28.3, the CloudNativePG metrics exporter opens its PostgreSQL connection as the postgres superuser via the pod-local Unix socket, then demotes the session with SET ROLE pg_monitor. SET ROLE changes only current_user; session_user remains postgres. Any SQL expression evaluated inside the scrape session can invoke RESET ROLE to recover real superuser privileges, then use COPY ... TO PROGRAM to spawn an OS-level subprocess as the postgres user inside the primary pod. The READ ONLY transaction flag does not block this; it gates writes to database state, not external processes. This vulnerability is fixed in 1.29.1 and 1.28.3.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS