CloudNativePG is a platform designed to manage PostgreSQL databases within Kubernetes environments. Prior to 1.28.4 and 1.29.2, CloudNativePG opened superuser connections without pinning searchpath in fillDefaultParameters in pkg/management/postgres/pool/profiles.go. A role holding DATABASE OWNER could create overloaded built-in operators in the public schema and change the database or role searchpath, causing instance-manager introspection queries such as SELECT COUNT() > 0 FROM pgcatalog.pgextension WHERE extname = $1 to execute attacker-controlled functions as the postgres superuser. The same trust issue affected direct sql.Open("pgx", ...) callsites and the public.usersearch SECURITY DEFINER function, enabling PostgreSQL superuser access, operating system command execution through COPY ... FROM PROGRAM, and access to the pod ServiceAccount token. This issue is fixed in versions 1.28.4, 1.29.2, and 1.30.0.

CloudNativePG is a platform designed to manage PostgreSQL databases within Kubernetes environments. Prior to 1.28.4 and 1.29.2, CloudNativePG embedded cleartext role passwords in ALTER ROLE and CREATE ROLE statements generated by SetUserPassword in pkg/management/postgres/utils/roles.go and appendPasswordOption in internal/management/controller/roles/postgres.go. When pgstatstatements was preloaded with trackutility enabled and an untrusted tenant held pgmonitor or pgreadallstats, the tenant could recover platform-managed superuser or application-owner passwords, reconnect through enabled superuser TCP access, and execute operating system commands in the database pod with COPY ... FROM PROGRAM. Clusters using SCRAM-SHA-256 verifiers in managed-role Secrets were not affected. This issue is fixed in versions 1.28.4, 1.29.2, and 1.30.0.

CloudNativePG is a platform designed to manage PostgreSQL databases within Kubernetes environments. Prior to 1.29.1 and 1.28.3, the CloudNativePG metrics exporter opens its PostgreSQL connection as the postgres superuser via the pod-local Unix socket, then demotes the session with SET ROLE pgmonitor. SET ROLE changes only currentuser; sessionuser remains postgres. Any SQL expression evaluated inside the scrape session can invoke RESET ROLE to recover real superuser privileges, then use COPY ... TO PROGRAM to spawn an OS-level subprocess as the postgres user inside the primary pod. The READ ONLY transaction flag does not block this; it gates writes to database state, not external processes. This vulnerability is fixed in 1.29.1 and 1.28.3.