CloudNativePG CVE-2026-55765

Exploitation requires all three of the following conditions simultaneously: (1) pg_stat_statements must be listed in PostgreSQL's shared_preload_libraries AND track_utility must be set to on - track_utility is off by default in many distributions, making this a non-default configuration; (2) the attacking tenant must hold the pg_monitor or pg_read_all_stats built-in role, which is commonly granted in multi-tenant clusters for observability; (3) a managed-role password reconciliation event must occur after the attacker gains their pg_monitor privilege so that the ALTER/CREATE ROLE statement appears in pg_stat_statements query history. Exploitation is further limited to clusters NOT using SCRAM-SHA-256 or MD5 verifiers in managed-role Secrets - clusters supplying pre-hashed passwords were never vulnerable. Superuser TCP access must be reachable from the tenant's connection to complete the lateral-movement step. Authentication is required at PR:L - the attacker must already be an authenticated PostgreSQL tenant.

The CVSS 8.5 score with vector AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H accurately reflects both the severity and the non-trivial prerequisites. AC:H is correct: three conditions must converge - pg_stat_statements must be in shared_preload_libraries, track_utility must be enabled (it is not the default), and the attacking tenant must hold pg_monitor or pg_read_all_stats. S:C and C/I/A:H are fully justified because COPY FROM PROGRAM executes OS-level commands inside the database pod, escaping the PostgreSQL trust boundary entirely. Clusters using SCRAM-SHA-256 verifiers in managed-role Secrets were explicitly not affected, which narrows the real-world population further. No EPSS data is provided in the input; given the specific configuration prerequisites and the absence of KEV listing, real-world exploitation risk is lower than the raw score implies, but the potential impact for affected configurations is catastrophic (full pod takeover with superuser credential reuse). The multi-tenant Kubernetes context elevates priority: shared clusters where different teams hold pg_monitor for observability are a common enterprise pattern, making the pg_monitor vector more realistic than it might appear. No data conflicts are present in the available sources; the vendor advisory, PR diff, and affected-version ranges are internally consistent.

A tenant in a shared Kubernetes PostgreSQL cluster holds the pg_monitor role granted for observability purposes. The cluster runs an unpatched CloudNativePG operator with pg_stat_statements loaded and track_utility=on. When the operator reconciles a managed role and calls ALTER ROLE app_owner WITH PASSWORD 'secret123', that literal SQL is captured by pg_stat_statements. The tenant queries SELECT query FROM pg_stat_statements WHERE query ILIKE '%ALTER ROLE%' to recover the cleartext password, then reconnects to PostgreSQL as app_owner or postgres, and issues COPY shell_cmd FROM PROGRAM 'id; cat /etc/passwd' to execute arbitrary commands inside the database pod. No public exploit code has been identified at time of analysis, but the technique requires only standard PostgreSQL client tooling.