CloudNativePG (role password handling, pg_stat_statements exposure): CREDENTIAL DISCLOSURE ACROSS THE TENANT BOUNDARY

Impact

CREDENTIAL DISCLOSURE ACROSS THE TENANT BOUNDARY: CloudNativePG sets role passwords by interpolating the cleartext into an ALTER ROLE utility statement. Utility statements are not parameterised, so pg_stat_statements records the literal when track_utility is on. A tenant role able to read those statistics harvests the platform-managed superuser and application-owner passwords on every rotation — meaning the credential refresh cycle keeps re-leaking rather than healing — reconnects as superuser, and where superuser TCP access is enabled reaches OS command execution in the database pod via COPY ... PROGRAM. The vendor is explicit that a default CNPG install is not affected: it needs pg_stat_statements preloaded, a tenant role granted pg_monitor or pg_read_all_stats, and enableSuperuserAccess: true. That combination is the normal shape of a managed-database product built on CNPG with a query-insights UI, which is exactly what a neocloud offering hosted Postgres alongside GPU capacity ends up building. An earlier fix suppressed log_statement only; pg_stat_statements is a separate subsystem and was untouched by it.

Who can reach it

Network, low privileges: a tenant-facing role with pg_monitor or pg_read_all_stats on a cluster that preloads pg_stat_statements. Escalation to OS execution additionally needs superuser TCP access enabled.

What to do

Upgrade to CloudNativePG 1.28.4, 1.29.2 or 1.30.0 and roll the instances. Rotate the superuser and application-owner passwords after upgrading, since anything captured is already captured. Clusters that supply a SCRAM-SHA-256 verifier in the managed-role Secret store a non-replayable hash and were never exposed — moving to that is the durable fix. Otherwise revoke pg_monitor/pg_read_all_stats from tenant roles, or turn off enableSuperuserAccess.

References