CloudNativePG: a database owner escalates to PostgreSQL superuser and OS command execution in the pod

Impact

CloudNativePG's instance manager opened superuser connections without pinning search_path, so a role holding DATABASE OWNER could shadow built-in operators in the public schema and have its own functions executed as the postgres superuser by routine introspection queries. From superuser, the advisory names two further steps: OS command execution via COPY ... FROM PROGRAM inside the database pod, and access to the pod's ServiceAccount token. That token is the pivot that matters on a shared cluster - a tenant-owned database becomes a foothold in the Kubernetes control plane, and CloudNativePG commonly backs the metadata and job-tracking databases that a GPU scheduling stack depends on. The same trust issue affected direct pgx callsites and the public.user_search SECURITY DEFINER function.

Who can reach it

Any authenticated database role that holds DATABASE OWNER on a database managed by CloudNativePG. No cluster credentials or node access required - ordinary tenant database access is the entry point.

What to do

Upgrade CloudNativePG to 1.28.4, 1.29.2, or 1.30.0; the operator rolls the instance-manager containers, which means a switchover and brief primary interruption per cluster rather than any node maintenance. Review which roles hold DATABASE OWNER on managed clusters, and treat any cluster where an untrusted role held it as potentially having leaked its pod ServiceAccount token - rotate it.

References