## Summary The StackGres metrics exporter connects to PostgreSQL as the cluster SUPERUSER with no role demotion, and fans a fresh superuser `dblink` session into every user database on each Prometheus scrape. The remote SQL it runs there contains unqualified catalog references and function calls, and nothing pins `search_path`. A low-privilege tenant who owns a database can set a database-level `search_path` and plant a shadow object in their own schema; the next scrape's superuser session resolves an unqualified name to the tenant's object and executes it with superuser privileges, reaching `COPY ... TO PROGRAM` for OS command execution in the primary PostgreSQL pod. This is the cross-project sibling of CloudNativePG CVE-2026-44477 / GHSA-423p-g724-fr39 (Critical 9.4). CNPG at least attempted a `SET ROLE pg_monitor` demotion (bypassable, because `session_user` stays superuser); StackGres never demotes at all. ## Affected versions All releases with the default metrics exporter, 1.x through 1.18.8, and HEAD `bbb3d06` (1.19.0-SNAPSHOT). The per-database superuser dblink fan-out has shipped since 2024-01. No patched version. ## Severity Critical, 9.4, `CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H`. CWE-426 (untrusted search path). ## Root cause Three facts compose the bug, all under `stackgres-k8s/src/operator/...`: 1. **Superuser exporter, no demotion.** `.../pgexporter/PostgresExporter.java:116-117,132-137` builds `DATA_SOURCE_NAME = postgresql://<superuser>@...` from `PatroniSecret.getSuperuserCredentials(...)`. There is no `SET ROLE` and no dedicated monitoring role (the file has zero such references). The exporter is enabled by default (`disableMetricsExporter: false`). 2. **Per-database superuser dblink fan-out.** `.../prometheus-postgres-exporter/queries.yaml` has several `master: true` queries that enumerate every non-template database and open a fresh `dblink` session into each as `user=' || CURRENT_USER` (the superuser), e.g. `pg_table_bloat` at `:514-583` (the same pattern appears in `pg_vaccuum_wraparound`, `pg_stat_progress_vacuum`, `pg_stat_progress_cluster`). 3. **Unqualified references inside the remote SQL, with no search_path pin.** The remote body of `pg_table_bloat` calls unqualified functions and tables that run in the tenant database: `current_setting(...)` (`:560`), `version()` (`:561`), and bare `pg_attribute`/`pg_class`/`pg_namespace`/`pg_stats` (`:568-573`). No `SET search_path` and no `options=-csearch_path` appears anywhere in the dblink connection strings or remote queries. A database-level `search_path` set by the database owner is inherited by every new session on that database, including the exporter's superuser dblink session. Unqualified name resolution therefore consults the tenant's schema first. ## Steps to reproduce As the owner of a tenant database `tenantdb` (a non-superuser role; ownership is all that is required): ```sql ALTER DATABASE tenantdb SET search_path = evil, pg_catalog; CREATE SCHEMA evil; CREATE TABLE evil.t(x int); -- give the bloat query a row to project CREATE FUNCTION evil.version() RETURNS text AS $$ BEGIN COPY (SELECT '') TO PROGRAM 'id > /tmp/pwned'; -- superuser-only; the dblink session is superuser RETURN 'PostgreSQL'; END $$ LANGUAGE plpgsql; ``` On the next scrape, the exporter's superuser dblink session runs `pg_table_bloat` inside `tenantdb`, resolves the unqualified `version()` call to `evil.version()`, and executes the `COPY ... TO PROGRAM` as the superuser. `/tmp/pwned` appears in the primary PostgreSQL pod. The `df()`/`mounts()` plpython3u helpers in `init.sql` are NOT the path: they run only in the exporter's master `postgres` session, where a tenant has no CREATE rights. The reachable primitive is shadowing the unqualified callables inside the per-database dblink bodies above. ## Proof The core primitive - an unqualified callable inside a superuser `dblink` session resolving to an attacker-owned object and executing `COPY ... TO PROGRAM` - was reproduced on a stand-in PostgreSQL. The StackGres-specific reach (default-on superuser exporter, per-database dblink with no search_path pin, unqualified `version()`/`pg_class` inside `pg_table_bloat`) was verified at source at `bbb3d06`. ## Impact OS command execution in the primary PostgreSQL pod as the database OS user, available to any tenant that owns a database (or any application reachable by SQL injection into such a database). Full read/write of every co-located database and a foothold for lateral movement in the pod and cluster. ## Remediation Mirror the CNPG fix: run the exporter as a dedicated NON-superuser role granted `pg_monitor` as the connecting role itself (not via `SET ROLE` from a superuser session, which is recoverable), and schema-qualify every catalog reference and function call in `queries.yaml`/`queries-1.23.yaml` with `pg_catalog.`. As defense in depth, prefix each remote dblink body with `SET search_path = pg_catalog`. ## Fix This security issue has been fixed in StackGres 1.19.0 ### Workaround for older version Older version may set ## Disclosure Responsible disclosure; CVE requested. Found by Cipher / Causal Security (https://causalsecurity.com/). If you need any additional information, let us know. ## Mitigation and workarounds The fix ships in **StackGres 1.19.0**; upgrading is the recommended remediation. In 1.19.0 the metrics exporter connects as a dedicated non-superuser `monitor` role (granted `pg_monitor`), routes every `dblink` through `SECURITY DEFINER` connect helpers, and pins `search_path` — so `session_user` is no longer the superuser and unqualified names can no longer be shadowed. For users who cannot upgrade from an affected version (<= 1.18.8), the following config-only workarounds mitigate the issue without patching the operator. Each was verified against the shipped `1.18.8` `queries.yaml` on PostgreSQL: with the default `search_path`, `pg_catalog` is resolved implicitly first, and either pinning `search_path` or schema-qualifying the catalog references prevents the tenant's shadow object from being executed by the exporter's superuser session. ### 1. Disable the metrics exporter (removes the vector entirely) The exporter is the whole attack surface; disabling it leaves no superuser `dblink` fan-out. ```yaml spec: configurations: observability: disableMetrics: true ``` Trade-off: StackGres built-in Prometheus metrics are no longer collected. ### 2. Override the affected queries to pin search_path (keeps monitoring) ConfigMap `<SGCluster name>-prometheus-postgres-exporter-config` allows to overwrite the operator's `queries.yaml` by setting label `stackgres-io/reconciliation-pause=true` and modifying the key `query.yaml`. Provide hardened copies of the per-database dblink queries, appending either ` options=-csearch_path=pg_catalog` to the dblink connection string, or a `SET search_path = pg_catalog, pg_temp`; prefix to the remote SQL body. The queries whose remote bodies contain unqualified references and must be overridden are: `pg_table_bloat`, `pg_index`, `pg_vaccuum_wraparound`, `pg_stat_progress_vacuum`, and `pg_stat_progress_cluster`. Applying the connection-string pin to every query that opens a dblink into user databases is the simplest robust option. After upgrading to `1.19.0` and removing the `stackgres-io/reconciliation-pause` from the ConfigMap will allow the operator to reconcile the `queries.yaml` to its generated value. Trade-off: the full query: and metrics: blocks must be reproduced per key, and require action on the future upgrade. ### 3. Do not grant tenants database ownership (defense in depth) The attack requires the tenant to reorder pg_catalog via `ALTER DATABASE <db> SET search_path = ...`, which only a database owner may do. If tenants connect to databases they do not own (and lack CREATE on any schema ahead of pg_catalog), the search-path-reordering primitive is unavailable and the default implicit pg_catalog-first resolution prevents shadowing. Trade-off: this changes the usual tenant-owned-database model and does not cover an application that owns its own database and is reachable by SQL injection.