Kubernetes Alert: 9.4 Severity RCE in CloudNativePG Enables PostgreSQL Superuser Takeover

In a critical discovery for Kubernetes-based database environments, researchers have unveiled a severe privilege escalation and Remote Code Execution (RCE) vulnerability in CloudNativePG (CNPG). The flaw, tracked as CVE-2026-44477 with a CVSS score of 9.4, allows low-privileged database users to pivot into full PostgreSQL superuser status and execute arbitrary commands on the underlying operating system.

CloudNativePG is widely used to manage the entire lifecycle of PostgreSQL databases in Kubernetes. To monitor these clusters, the platform employs a metrics exporter.

The vulnerability lies in how this exporter establishes its connection. It initially connects as the postgres superuser via a local Unix socket and then attempts to “demote” itself using the SET ROLE pg_monitor command. However, this demotion is only skin-deep.

While the current_user changes, the session_user remains postgres. This residual identity provides the foothold for a devastating attack chain: any SQL expression evaluated during a metrics scrape can simply call RESET ROLE to recover full superuser privileges.

Researchers identified two distinct ways this flaw can be weaponized in the wild:

• Path 1: Custom Metric Sabotage: Any database user who owns a schema on the search_path of a scraped database can “shadow” a common function used in a custom metric query. Within one scrape interval (typically 30 seconds), their malicious shadow expression executes with superuser rights.
• Path 2: The “Stock” Vulnerability: Even deployments using only default configurations are at risk. A specific metric, pg_extensions, used an unqualified call that could be shadowed by any non-superuser who owns a user database.

Once superuser status is recovered, attackers can use the COPY … TO PROGRAM command to spawn an OS-level subprocess as the postgres user inside the primary pod.

This vulnerability affects all deployments on any supported release with default monitoring enabled.

• Affected Versions: All versions prior to 1.28.3 and version 1.29.0.
• High-Risk Targets: Multi-tenant platforms that allow customers to influence custom metric query bodies are at the highest risk.

The CloudNativePG team has released three separate patches to address the issue, now available in Patched Versions 1.28.3 and 1.29.1.

The core fix introduces a dedicated, non-superuser role—cnpg_metrics_exporter—and maps it via peer authentication. This ensures the session_user is never a superuser, breaking the RESET ROLE escalation primitive entirely.

If you cannot upgrade your operator immediately, researchers recommend several high-priority mitigations:

1. Schema-Qualify Everything: Manually add pg_catalog. prefixes to all functions and views in your custom metric queries (e.g., pg_catalog.now()).
2. Restrict Database Ownership: Ensure only fully trusted roles own user databases in scraped clusters.
3. Limit Scrape Scope: Avoid using the target_databases: ‘*’ wildcard unless every database and its owner in the cluster is fully trusted.
4. Close the SQL Injection Pivot: Treat any multi-tenant metric query as a critical trust boundary.