CVE-2026-44477 - CloudNativePG metrics exporter RCE

CloudNativePG’s metrics exporter could connect through the pod-local Unix socket as PostgreSQL superuser, then demote with SET ROLE pg_monitor. Because the authenticated session_user remained postgres, SQL evaluated during metrics scraping could regain superuser privileges and use COPY ... TO PROGRAM for OS command execution as the postgres user inside the primary pod.

The stock monitoring path and custom metrics were both relevant: unqualified catalog references and attacker-controlled database objects could turn a scrape into a privilege escalation path.

When to use it

Use this recipe when a Kubernetes platform, database service, or application repository deploys CloudNativePG metrics exporters or custom PostgreSQL metrics. It is built for source-code and platform remediation, monitoring privilege review, SQL qualification hygiene, and audit evidence that metrics scraping cannot regain PostgreSQL superuser or execute pod-level commands.

Inputs

  • CloudNativePG version, operator manifests, Cluster resources, custom metrics definitions, exporter configuration, and PostgreSQL role model.
  • SQL used by built-in or custom metrics, schema qualification policy, database object ownership, pod security context, and monitoring service account permissions.
  • Regression fixtures for attacker-controlled database objects, qualified catalog references, role switching, and safe metric scraping.
  • Boundary evidence: affected clusters, pod privileges, network reach, logs, superuser access paths, and rollout owner.

Affected versions

Package Vulnerable versions Fixed versions
github.com/cloudnative-pg/cloudnative-pg <1.28.3; >=1.29.0, <1.29.1 1.28.3, 1.29.1

Indicator-of-exposure

  • CloudNativePG operator or manifests resolve to an affected version.
  • Default monitoring is enabled.
  • Custom metric queries contain unqualified identifiers.
  • Any scraped database is owned by, writable by, or schema-influenced by roles that are not fully trusted.
  • Multi-tenant users can provide or affect metrics query bodies.

Quick checks:

rg -n "cloudnative-pg|CloudNativePG|cnpg|default-monitoring|target_databases|pg_extensions|custom metric|current_database\\(|COPY .* PROGRAM|pg_monitor" .
kubectl get deployment -A -o yaml 2>/dev/null | rg -i "cloudnative-pg|cnpg"
helm list -A 2>/dev/null | rg -i "cloudnative|cnpg"

Remediation strategy

  • Upgrade CloudNativePG to 1.28.3+ or 1.29.1+.
  • Ensure metrics exporter authenticates as the dedicated non-superuser metrics role introduced by the patch.
  • Requalify all copied or custom monitoring SQL with explicit pg_catalog. references.
  • Restrict target_databases: "*" to trusted databases where possible.
  • Review database ownership and schema creation privileges for scraped databases, especially PostgreSQL versions before 15 where public defaults can be permissive.

The prompt

You are remediating CVE-2026-44477 in CloudNativePG metrics exporter behavior.
Produce exactly one output:

- A reviewer-ready PR/change request that upgrades CloudNativePG, refreshes
  monitoring config, narrows custom metric risk, updates generated artifacts,
  and documents operator rollout actions, or
- TRIAGE.md if this repository does not control an affected CloudNativePG
  deployment.

## Rules

- Scope only CVE-2026-44477 and directly related monitoring, database-role,
  and Kubernetes rollout controls.
- Do not run SQL payloads that call `RESET ROLE`, `RESET SESSION
  AUTHORIZATION`, `COPY TO PROGRAM`, shell commands, or privilege-escalation
  probes.
- Do not dump database contents, secrets, service account tokens, pod files,
  connection strings, or customer data.
- Do not rely on schema-qualifying metrics as a complete fix if the exporter
  still authenticates as superuser.
- Do not auto-merge.

## Steps

1. Inventory Helm charts, Kustomize, manifests, Terraform, operator images,
   GitOps apps, monitoring ConfigMaps, custom metrics, docs, and SBOMs for
   CloudNativePG.
2. Determine every operator version. A target is vulnerable if it is `<1.28.3`
   or `>=1.29.0, <1.29.1`.
3. Find default monitoring and custom metrics. Flag unqualified catalog
   functions/views, `target_databases: "*"`, user-owned schemas on search_path,
   and customer-supplied metric query paths.
4. Upgrade CloudNativePG to `1.28.3+` or `1.29.1+`. For replica clusters,
   document source-primary-first rollout ordering so the metrics role exists
   before replicas scrape.
5. Refresh copied `default-monitoring.yaml` or custom monitoring ConfigMaps so
   catalog references are explicitly schema-qualified.
6. Add policy or review checks for custom metrics:
   - no unqualified `pg_catalog` functions/views;
   - no metrics supplied by untrusted tenants without security review;
   - no broad `target_databases: "*"` unless owners are trusted;
   - explicit grants to the dedicated metrics role where custom queries need
     additional read access.
7. Add safe static tests or policy checks for monitoring YAML. Do not execute
   exploit SQL.
8. Add a PR body section named `CVE-2026-44477 operator actions` covering:
   operator versions, clusters affected, monitoring ConfigMaps changed,
   custom metrics requiring owner review, rollout order, and whether pod logs
   should be reviewed for suspicious metric-query activity.
9. Run validation: manifest render, Helm/Kustomize checks, policy tests,
   Kubernetes schema validation, unit tests, SBOM refresh, and dependency scan.
10. Use PR title:
    `fix(sec): remediate CloudNativePG metrics exporter RCE`.

## Stop conditions

- CloudNativePG is not present or is fully managed outside this repository.
- All controlled clusters already run patched versions and monitoring config is
  current.
- Verification would require running privilege-escalation SQL or touching
  production databases.
- Custom metrics are owned by another team; document exact owners and required
  review in TRIAGE.md.

Output contract

  • A reviewer-ready PR or change request that upgrades CloudNativePG, requalifies metrics SQL, contains monitoring privileges, adds regression checks, and documents cluster rollout.
  • Or a TRIAGE.md file that lists inspected manifests, owner, observed version, metrics exposure, privilege boundary, required fix, and residual risk.
  • The output must include exact validation commands and must not run COPY ... TO PROGRAM, print database secrets, or test against production primary pods.

Verification - what the reviewer looks for

  • Operator versions are patched in every controlled environment.
  • Monitoring SQL copied into the repo uses explicit catalog qualification.
  • Custom metrics and target_databases posture are reviewed.
  • Rollout notes address source-primary and replica ordering.
  • No exploit SQL or sensitive database output appears in the PR.

Watch for

  • Old copied default-monitoring.yaml files that do not change when the operator image changes.
  • Multi-tenant platforms where customers can influence metric queries.
  • PostgreSQL pre-15 public schema defaults in scraped databases.

References