Unknown · Cloudnativepg · CVE-2026-44477
**Name of the Vulnerable Software and Affected Versions**
CloudNativePG versions prior to 1.28.3
CloudNativePG versions prior to 1.29.1
**Description**
The metrics exporter in CloudNativePG opens a PostgreSQL connection as the `postgres` superuser via the pod-local Unix socket and subsequently demotes the session using `SET ROLE pg monitor`. Because `SET ROLE` only modifies the `current user` while the `session user` remains `postgres`, any SQL expression evaluated during a scrape session can execute `RESET ROLE` to recover superuser privileges. An attacker can then use the `COPY ... TO PROGRAM` command to spawn an OS-level subprocess as the `postgres` user within the primary pod. The `READ ONLY` transaction flag does not prevent this as it only restricts writes to the database state, not external processes.
There are two primary exploitation paths:
1. Custom metric queries using unqualified identifiers: A user owning a schema on the `search path` can plant a shadow object. When the exporter evaluates the query, the shadow expression executes with superuser privileges.
2. Default monitoring configuration: The `pg extensions` metric in `default-monitoring.yaml` used an unqualified `current database()` call across all target databases. Any non-superuser owning a user database could shadow this function to trigger the escalation.
This allows a low-privileged database role to escalate to PostgreSQL superuser and achieve remote code execution (RCE) as the `postgres` user inside the primary pod.
**Recommendations**
Upgrade to version 1.28.3 or 1.29.1.
As a temporary workaround, schema-qualify all identifiers in custom metric queries by using explicit `pg catalog.` prefixes for all catalog functions and views.
Restrict database ownership to ensure only fully trusted roles own user databases in scraped clusters.
Limit the scope of `target databases: '*'` queries to specific, known-safe databases.
Avoid exposing metric query SQL to untrusted users.