CVE-2026-44477 is a critical privilege escalation (CVSS 9.9) in the CloudNativePG metrics exporter for PostgreSQL on Kubernetes. A database user can regain superuser rights and run commands inside the primary pod. Upgrade to 1.28.3 or 1.29.1, depending on which release line you run today.
What's affected
From the project advisory for the cloudnative-pg operator image:
- Affected: all versions before 1.28.3, and 1.29.0.
- Fixed: 1.28.3 and 1.29.1.
If you run an older minor line, the advisory lists everything below 1.28.3 as affected, so plan a move to a supported release rather than waiting for a backport.
The advisory describes two paths. The first needs a custom metric query that contains an unqualified table or function name, and a database user who owns a schema on the search path of a scraped database. The second path is described in the full advisory. Read it if you cannot upgrade soon.
How to check if you're exposed
Find the operator version in your cluster. The default install uses the cnpg-system namespace, so adjust if yours differs:
kubectl get deploy -n cnpg-system -o jsonpath='{.items[*].spec.template.spec.containers[*].image}'
Compare the tag with the fixed versions above. Then check for custom monitoring queries, which the first path depends on:
Also list your Cluster resources and look for monitoring sections that reference custom queries:
kubectl get clusters.postgresql.cnpg.io -A -o yaml | grep -n -i -A5 monitoring
Any query that names tables or functions without a schema is worth reviewing.
What to do now
- Upgrade the operator to 1.28.3 or 1.29.1 and let it roll the managed PostgreSQL instances.
- Review custom metric queries and qualify every table, view and function with its schema name.
- Audit which database users can create objects in schemas on the search path of scraped databases, and remove that right where it is not needed.
- Check recent activity on the primary for unexpected objects, and for child processes of the postgres user inside the pod.
- Keep the metrics endpoint off untrusted networks while you work through the upgrade.
Why it matters
The advisory names CWE-250 (execution with unnecessary privileges), CWE-271 (privilege dropping issues) and CWE-426 (untrusted search path) in the record. The exporter opened its connection as the postgres superuser and then lowered privileges with SET ROLE pg_monitor. That changes the current role but not the session user, so the superuser identity stays underneath.
Any SQL that runs in that session can switch back to superuser. From there, PostgreSQL's ability to start a program from a COPY command gives an operating system foothold as the postgres user inside the primary pod. The read only transaction flag does not help, because it limits writes to database state and not external processes.
The practical lesson is to connect monitoring as a low privilege login from the start rather than demoting a superuser session. The record does not mark this CVE as KEV, and the advisory does not report exploitation.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Does this need an attacker to be a database user?
Yes. The record shows low privileges required. A database user who can plant objects where a metric query will resolve them is the described starting point.
Does making metric queries schema qualified fix it?
It closes the first path described in the advisory, but the root cause is in the exporter, so upgrade as well.
Sources
Last reviewed: 19 October 2026.
