Merge commit from fork

The metrics exporter authenticated as the `postgres` superuser and
demoted the session with `SET ROLE pg_monitor`. A database user owning
a schema on the scrape session's `search_path` could subvert that by
running `RESET ROLE` to recover superuser privileges and
`COPY ... TO PROGRAM` to execute OS commands inside the primary pod
(`CVE-2026-44477` / `GHSA-423p-g724-fr39`).

Replace the postgres-superuser connection used by the metrics exporter
with a dedicated `cnpg_metrics_exporter` role, granted only
`pg_monitor`, mapped via `pg_ident.conf` for peer authentication on the
local Unix socket. The metrics exporter's `session_user` is therefore
never a superuser, so `RESET ROLE` and `SET SESSION AUTHORIZATION`
cannot recover superuser, and `COPY ... TO PROGRAM` (which requires
`pg_execute_server_program`, not granted by `pg_monitor`) becomes
unavailable.

As defense in depth, the monitoring transaction prepends `pg_catalog`
to the connection's `search_path` so unqualified catalog identifiers
cannot resolve to user-planted shadow objects, and the
`target_databases: '*'` expansion filters by
`pg_catalog.has_database_privilege(datname, 'CONNECT')`.

The role is created at bootstrap, alongside `streaming_replica` in
`configureInstancePermissions`, so the first scrape after a cluster
comes up has the role available. The Reconcile loop additionally
enforces drift correction on every iteration, and clears any password
set out-of-band so the role cannot be authenticated by password
regardless of operator pre-creation. The role is excluded from
`bootstrap.initdb.import` so it is created cleanly per cluster.

Databases skipped during `target_databases: '*'` expansion for missing
`CONNECT` are logged at Debug level, surfacing what would otherwise be
silent drops.

Documentation covers the role's privilege model, the `GRANT` statements
required for custom queries that read user-owned tables or target
databases where `PUBLIC CONNECT` has been revoked, manual recovery for
replica clusters upgraded before their source primary, and the upgrade
impact in `installation_upgrade.md`.

Reported-by: Mehmet Ince
Assisted-by: Claude

Signed-off-by: Gabriele Bartolini <gabriele.bartolini@enterprisedb.com>
Signed-off-by: Armando Ruocco <armando.ruocco@enterprisedb.com>
Signed-off-by: Leonardo Cecchi <leonardo.cecchi@enterprisedb.com>
Signed-off-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
Co-authored-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
Co-authored-by: Armando Ruocco <armando.ruocco@enterprisedb.com>
Co-authored-by: Leonardo Cecchi <leonardo.cecchi@enterprisedb.com>

Author: 4 people

api/v1/cluster_types.go

@@ -110,6 +110,12 @@ const (
 	// PGBouncerPoolerUserName is the name of the role to be used for
 	PGBouncerPoolerUserName = "cnpg_pooler_pgbouncer"
 
+	// MetricsExporterUserName is the name of the dedicated role used by the
+	// metrics exporter to connect to PostgreSQL. This role has pg_monitor
+	// granted and is never a superuser, so session_user never escalates via
+	// RESET ROLE.
+	MetricsExporterUserName = "cnpg_metrics_exporter"
+
 	// MissingWALDiskSpaceExitCode is the exit code the instance manager
 	// will use to signal that there's no more WAL disk space
 	MissingWALDiskSpaceExitCode = 4

docs/src/installation_upgrade.md

@@ -267,6 +267,22 @@ removed before installing the new one. This won't affect user data but
 only the operator itself.
 
 
+### Upgrading to 1.29.1 or 1.28.3
+
+Version 1.29.1 and 1.28.3 ship the fix for `CVE-2026-44477` /
+`GHSA-423p-g724-fr39`. The metrics exporter now authenticates as a
+dedicated `cnpg_metrics_exporter` role with `pg_monitor` privileges
+only, instead of the `postgres` superuser.
+
+Custom monitoring queries that read user-owned tables, or use
+`target_databases: '*'` against databases where `PUBLIC` `CONNECT`
+has been revoked, need explicit `GRANT` statements to
+`cnpg_metrics_exporter`. See ["Custom query privileges and
+safety"](monitoring.md#custom-query-privileges-and-safety) and ["Manually creating
+the metrics exporter
+role"](monitoring.md#manually-creating-the-metrics-exporter-role) in
+the monitoring documentation.
+
 ### Upgrading to 1.29.0 or 1.28.x
 
 :::info[Important]

docs/src/monitoring.md

@@ -36,10 +36,17 @@ more `ConfigMap` or `Secret` resources (see the
 
 All monitoring queries that are performed on PostgreSQL are:
 
-- atomic (one transaction per query)
-- executed with the `pg_monitor` role
+- atomic (one read-only transaction per query)
+- executed as the `cnpg_metrics_exporter` role (a member of `pg_monitor`)
 - executed with `application_name` set to `cnpg_metrics_exporter`
-- executed as user `postgres`
+
+The connection uses peer authentication on the pod-local Unix socket;
+because `session_user` is never a superuser, the monitoring session
+cannot escalate via `RESET ROLE` or `RESET SESSION AUTHORIZATION`. Do
+not grant additional privileges or role memberships to
+`cnpg_metrics_exporter` beyond `pg_monitor` and the table-level grants
+required by your custom queries: any extra membership flows into the
+scrape session via inheritance and weakens this property.
 
 Please refer to the "Predefined Roles" section in PostgreSQL
 [documentation](https://www.postgresql.org/docs/current/predefined-roles.html)
@@ -494,6 +501,42 @@ Take care that the referred resources have to be created **in the same namespace
     and a key `queryName` containing the overwritten query name.
 :::
 
+#### Custom query privileges and safety
+
+:::warning
+    Custom queries run as the `cnpg_metrics_exporter` role, which inherits
+    `pg_monitor`. Queries within `pg_monitor`'s scope (catalog reads,
+    `pg_stat_*` views, configuration parameters) work without modification.
+    Queries that read user-owned tables or superuser-only catalogs (e.g.
+    `pg_authid`, `pg_subscription`) need explicit grants. Reading a table
+    also requires USAGE on its schema:
+
+    ```sql
+    GRANT USAGE ON SCHEMA myschema TO cnpg_metrics_exporter;
+    GRANT SELECT ON TABLE myschema.mytable TO cnpg_metrics_exporter;
+    ```
+
+    Every database in `target_databases` must allow
+    `cnpg_metrics_exporter` to `CONNECT`. On clusters that have
+    revoked `CONNECT` from `PUBLIC` for a database, grant it
+    explicitly to that role:
+
+    ```sql
+    GRANT CONNECT ON DATABASE domainapp TO cnpg_metrics_exporter;
+    ```
+
+    Prefer an explicit list of trusted databases (e.g.
+    `target_databases: ["domainapp"]`) over the `"*"` wildcard. The
+    wildcard scrapes every database the role can connect to and
+    silently skips the rest, so an explicit list makes a missing grant
+    easier to notice. Use `"*"` only when the query is meant to
+    collect per-database metrics across the whole cluster.
+
+    Schema-qualify catalog references (`pg_catalog.now()`,
+    `pg_catalog.current_database()`) to prevent `search_path` shadowing
+    by user-owned objects.
+:::
+
 #### Example of a user defined metric
 
 Here you can see an example of a `ConfigMap` containing a single custom query,
@@ -570,17 +613,22 @@ Database auto-discovery can be enabled for a specific query by specifying a
 *shell-like pattern* (i.e., containing `*`, `?` or `[]`) in the list of
 `target_databases`. If provided, the operator will expand the list of target
 databases by adding all the databases returned by the execution of `SELECT
-datname FROM pg_database WHERE datallowconn AND NOT datistemplate` and matching
-the pattern according to [path.Match()](https://pkg.go.dev/path#Match) rules.
+datname FROM pg_catalog.pg_database WHERE datallowconn AND NOT datistemplate
+AND pg_catalog.has_database_privilege(datname, 'CONNECT')` and matching the
+pattern according to [path.Match()](https://pkg.go.dev/path#Match) rules.
+Databases on which `cnpg_metrics_exporter` lacks the `CONNECT` privilege are
+silently skipped; if you want a database with revoked `PUBLIC` access to be
+scraped, grant `CONNECT` explicitly (see "Custom query privileges and safety"
+above).
 
 :::note
     The `*` character has a [special meaning](https://yaml.org/spec/1.2/spec.html#id2786448) in yaml,
     so you need to quote (`"*"`) the `target_databases` value when it includes such a pattern.
 :::
 
 It is recommended that you always include the name of the database
-in the returned labels, for example using the `current_database()` function
-as in the following example:
+in the returned labels, for example using the `pg_catalog.current_database()`
+function as in the following example:
 
 ```yaml
 some_query: |
@@ -757,6 +805,33 @@ CloudNativePG is inspired by the PostgreSQL Prometheus Exporter, but
 presents some differences. In particular, the `cache_seconds` field is not implemented
 in CloudNativePG's exporter.
 
+### Manually creating the metrics exporter role
+
+The operator creates the `cnpg_metrics_exporter` PostgreSQL role on the
+primary during reconciliation; it then propagates to standbys and
+replica clusters via streaming replication.
+
+If the role is missing (replica cluster upgraded before its primary,
+restore from a backup that predates the role, accidental removal),
+recreate it as a superuser on the writable primary of the replication
+chain (the source primary, not a designated primary of a replica
+cluster):
+
+```sql
+CREATE ROLE cnpg_metrics_exporter WITH LOGIN NOSUPERUSER NOCREATEDB
+    NOCREATEROLE NOREPLICATION NOBYPASSRLS INHERIT;
+GRANT pg_monitor TO cnpg_metrics_exporter;
+```
+
+If your custom monitoring queries need access to objects outside
+`pg_monitor`'s scope, grant the necessary privileges explicitly. SELECT
+on a table also requires USAGE on its schema:
+
+```sql
+GRANT USAGE ON SCHEMA myschema TO cnpg_metrics_exporter;
+GRANT SELECT ON TABLE myschema.mytable TO cnpg_metrics_exporter;
+```
+
 ## Monitoring the CloudNativePG operator
 
 The operator internally exposes [Prometheus](https://prometheus.io/) metrics

docs/src/release_notes/v1.28.md

@@ -17,6 +17,29 @@ on the release branch in GitHub.
 
 ### Security and Supply Chain
 
+- **`CVE-2026-44477` / `GHSA-423p-g724-fr39`: metrics exporter privilege
+  escalation**: the metrics exporter no longer authenticates as the
+  `postgres` superuser. It now uses a dedicated `cnpg_metrics_exporter`
+  role with `pg_monitor` privileges only, closing a chain that let a
+  low-privilege database user gain PostgreSQL superuser.
+  ([`GHSA-423p-g724-fr39`](https://github.com/cloudnative-pg/cloudnative-pg/security/advisories/GHSA-423p-g724-fr39)) <!-- 1.29 1.28 1.25 -->
+
+    Upgrade impact: custom monitoring queries that read user-owned tables,
+    or use `target_databases: '*'` against databases where
+    `PUBLIC CONNECT` has been revoked, need explicit `GRANT` statements to
+    `cnpg_metrics_exporter`. See ["Custom query privileges and
+    safety"](../monitoring.md#custom-query-privileges-and-safety) and ["Manually
+    creating the metrics exporter
+    role"](../monitoring.md#manually-creating-the-metrics-exporter-role)
+    in the monitoring documentation.
+
+    For replica clusters, upgrade the source primary cluster before any
+    replica clusters that consume from it. The `cnpg_metrics_exporter`
+    role is created on the source primary and replicates downstream; a
+    replica cluster upgraded first will scrape against a missing role
+    until the source primary upgrades. The manual-recovery section
+    linked above also covers replica clusters.
+
 - **Schema-qualified catalog references in default monitoring queries**:
   hardened the shipped monitoring configuration and documentation samples by
   qualifying every `pg_catalog` object explicitly. Unqualified references

docs/src/release_notes/v1.29.md

@@ -17,6 +17,29 @@ on the release branch in GitHub.
 
 ### Security and Supply Chain
 
+- **`CVE-2026-44477` / `GHSA-423p-g724-fr39`: metrics exporter privilege
+  escalation**: the metrics exporter no longer authenticates as the
+  `postgres` superuser. It now uses a dedicated `cnpg_metrics_exporter`
+  role with `pg_monitor` privileges only, closing a chain that let a
+  low-privilege database user gain PostgreSQL superuser.
+  ([`GHSA-423p-g724-fr39`](https://github.com/cloudnative-pg/cloudnative-pg/security/advisories/GHSA-423p-g724-fr39)) <!-- 1.29 1.28 1.25 -->
+
+    Upgrade impact: custom monitoring queries that read user-owned tables,
+    or use `target_databases: '*'` against databases where
+    `PUBLIC CONNECT` has been revoked, need explicit `GRANT` statements to
+    `cnpg_metrics_exporter`. See ["Custom query privileges and
+    safety"](../monitoring.md#custom-query-privileges-and-safety) and ["Manually
+    creating the metrics exporter
+    role"](../monitoring.md#manually-creating-the-metrics-exporter-role)
+    in the monitoring documentation.
+
+    For replica clusters, upgrade the source primary cluster before any
+    replica clusters that consume from it. The `cnpg_metrics_exporter`
+    role is created on the source primary and replicates downstream; a
+    replica cluster upgraded first will scrape against a missing role
+    until the source primary upgrades. The manual-recovery section
+    linked above also covers replica clusters.
+
 - **Schema-qualified catalog references in default monitoring queries**:
   hardened the shipped monitoring configuration and documentation samples by
   qualifying every `pg_catalog` object explicitly. Unqualified references

internal/cmd/manager/instance/run/lifecycle/run.go

@@ -194,6 +194,11 @@ func configureInstancePermissions(ctx context.Context, instance *postgres.Instan
 		return err
 	}
 
+	if err = postgres.SetupMetricsExporterRole(ctx, tx); err != nil {
+		_ = tx.Rollback()
+		return err
+	}
+
 	return tx.Commit()
 }
 

internal/management/controller/instance_controller.go

@@ -320,6 +320,10 @@ func (r *InstanceReconciler) Reconcile(
 		return reconcile.Result{}, fmt.Errorf("cannot reconcile pgbouncer integration: %w", err)
 	}
 
+	if err := r.reconcileMetricsExporterAuthUser(ctx, postgresDB); err != nil {
+		return reconcile.Result{}, fmt.Errorf("cannot reconcile metrics exporter integration: %w", err)
+	}
+
 	// Reconcile postgresql.auto.conf file permissions (< PG 17)
 	// IMPORTANT: this needs a database connection to determine
 	// the PostgreSQL major version
@@ -841,6 +845,43 @@ func (r *InstanceReconciler) reconcilePgbouncerAuthUser(
 	return tx.Commit()
 }
 
+// reconcileMetricsExporterAuthUser ensures the dedicated cnpg_metrics_exporter
+// PostgreSQL role exists and has pg_monitor granted. This role is used by the
+// metrics exporter instead of the postgres superuser so that session_user is
+// never a superuser and RESET ROLE has no escalation effect.
+func (r *InstanceReconciler) reconcileMetricsExporterAuthUser(
+	ctx context.Context,
+	db *sql.DB,
+) error {
+	ok, err := r.instance.IsPrimary()
+	if err != nil {
+		return fmt.Errorf("unable to check if instance is primary: %w", err)
+	}
+	if !ok {
+		return nil
+	}
+	return setupMetricsExporterRole(ctx, db)
+}
+
+// setupMetricsExporterRole opens a transaction and delegates to the shared
+// helper that creates or repairs the cnpg_metrics_exporter role.
+func setupMetricsExporterRole(ctx context.Context, db *sql.DB) error {
+	tx, err := db.BeginTx(ctx, nil)
+	if err != nil {
+		return err
+	}
+	defer func() {
+		// This is a no-op when the transaction is committed
+		_ = tx.Rollback()
+	}()
+
+	if err := postgresManagement.SetupMetricsExporterRole(ctx, tx); err != nil {
+		return err
+	}
+
+	return tx.Commit()
+}
+
 // reconcileClusterRoleWithoutDB updates this instance's configuration files
 // according to the role written in the cluster status
 func (r *InstanceReconciler) reconcileClusterRoleWithoutDB(