Attack Chain

1. An attacker gains access to a low-privileged database role (e.g., the default app role).
2. The attacker identifies a target database being scraped by the CloudNativePG metrics exporter.
3. (Path 1: Custom Metric Queries) The attacker plants a shadow object (e.g., function, view) in a schema on the search_path of the target database, with the same name as an unqualified identifier used in a custom metric query.
4. (Path 2: Default Monitoring) The attacker plants a shadow object named current_database() in a user database, exploiting the unqualified call in the pg_extensions metric.
5. When the metrics exporter next scrapes the database, the shadow object’s code is executed within the exporter’s session_user = postgres session.
6. The attacker’s code executes RESET ROLE to recover superuser privileges within the scrape session.
7. The attacker’s code then uses COPY ... TO PROGRAM to execute an arbitrary OS command as the postgres user inside the primary pod.
8. The attacker achieves arbitrary OS command execution inside the database pod, potentially leading to further lateral movement or data exfiltration.

Impact

Successful exploitation allows privilege escalation from a low-privileged database role to PostgreSQL superuser, combined with arbitrary OS command execution as the postgres user inside the primary pod. A web application SQL injection vulnerability in an app backed by a CloudNativePG cluster is sufficient to pivot to database-pod RCE. All deployments with default monitoring enabled or custom metric queries containing unqualified catalog references are affected. Multi-tenant platforms are at the highest risk.

Recommendation

• Upgrade CloudNativePG to v1.28.3 or later, or v1.29.1 or later to incorporate the fixes described in the advisory, specifically addressing CVE-2026-44477.
• Apply the workaround by schema-qualifying all identifiers in custom metric queries as described in the advisory, using explicit pg_catalog. prefixes.
• Restrict database ownership to fully trusted roles, ensuring only these roles own user databases in scraped clusters to limit the exploit’s impact, per the advisory recommendations.
• Deploy the Sigma rule “Detect CloudNativePG Postgres User Pod RCE” to identify potential exploitation attempts leveraging the COPY command to program, based on process creation logs.
• Deploy the Sigma rule “Detect CloudNativePG Metrics Exporter PrivEsc via Shadowed current_database” to detect the shadowing of current_database function.