CVE-2026-44477
Privilege Escalation via SET ROLE in CloudNativePG Metrics Exporter
Publication date: 2026-05-28
Last updated on: 2026-05-28
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| cloudnative_pg | cloudnative_pg | to 1.29.1 (inc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-250 | The product performs an operation at a privilege level that is higher than the minimum level required, which creates new weaknesses or amplifies the consequences of other weaknesses. |
| CWE-271 | The product does not drop privileges before passing control of a resource to an actor that does not have those privileges. |
| CWE-426 | The product searches for critical resources using an externally-supplied search path that can point to resources that are not under the product's direct control. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
CVE-2026-44477 is a critical security vulnerability in CloudNativePG's metrics exporter. The exporter connects to PostgreSQL as the superuser via a Unix socket and then demotes the session using SET ROLE pg_monitor. However, the session_user remains as the superuser (postgres), allowing an attacker to regain superuser privileges by invoking RESET ROLE.
This privilege escalation enables the attacker to execute arbitrary operating system commands inside the primary pod by using the COPY ... TO PROGRAM feature. The vulnerability can be exploited through two main paths: one involving custom metric queries with unqualified identifiers that can be shadowed by an attacker, and another involving the default monitoring query that includes an unqualified current_database() call, which can be shadowed by any non-superuser owning a database.
The vulnerability was fixed by introducing a dedicated cnpg_metrics_exporter role with limited privileges and by schema-qualifying all unqualified catalog references in monitoring queries to prevent shadowing.
How can this vulnerability impact me? :
This vulnerability allows a low-privilege database user to escalate their privileges to PostgreSQL superuser and execute arbitrary operating system commands inside the primary pod hosting the database.
An attacker exploiting this vulnerability can gain full control over the database and the underlying operating system environment, potentially leading to data breaches, unauthorized data modification, or disruption of services.
All deployments with default monitoring enabled are vulnerable, as well as those using custom metric queries with unqualified catalog references, making the impact widespread unless patched or mitigated.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
Detection of this vulnerability involves checking if your CloudNativePG deployment is running a vulnerable version prior to 1.28.3 or between 1.29.0 and 1.29.1, and if the metrics exporter connects as the PostgreSQL superuser via the pod-local Unix socket.
You can inspect the monitoring queries for unqualified identifiers or shadowed built-in objects that could be exploited.
Commands to help detect potential exploitation or presence of the vulnerability include:
- Check the CloudNativePG version running in your environment to confirm if it is vulnerable.
- Review the roles and permissions in PostgreSQL, especially if the metrics exporter is running as the postgres superuser or a role with elevated privileges.
- Query for any shadowed objects or unqualified identifiers in custom metric queries that could be exploited.
- Monitor for unusual COPY ... TO PROGRAM commands or subprocess executions initiated by the postgres user inside the primary pod.
Specific commands are not provided in the resources, but general PostgreSQL commands to check roles and queries include:
- SELECT version(); -- to check PostgreSQL version
- SELECT rolname, rolsuper FROM pg_roles WHERE rolname = 'cnpg_metrics_exporter' OR rolname = 'postgres';
- Review monitoring queries for unqualified identifiers or suspicious SQL.
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation steps include upgrading CloudNativePG to versions 1.28.3 or 1.29.1 or later, where the vulnerability is fixed.
The fix involves introducing a dedicated cnpg_metrics_exporter role with only pg_monitor privileges, removing the need for superuser connections by the metrics exporter.
Additional mitigation measures include:
- Schema-qualify all catalog references in custom monitoring queries to prevent shadowing attacks.
- Restrict database ownership to trusted users to reduce the risk of planting shadow objects.
- Limit the scope of target_databases for monitoring to minimize exposure.
- Avoid exposing metric query SQL to untrusted users.
These steps help prevent privilege escalation and remote code execution via the metrics exporter.