CloudNativePG EUVD-2026-63687

Exploitation requires the attacker to already hold DATABASE OWNER (or an equivalent role able to CREATE objects in a writable schema such as public and to run ALTER DATABASE/ALTER ROLE ... SET search_path) on a database managed by a vulnerable CloudNativePG instance (< 1.28.4, or 1.29.0-1.29.1). The concrete prerequisites are: (1) the operator opening a superuser connection with an unpinned search_path - the default behavior before the fix; (2) a schema the attacker can write to (public by default) so an overloaded built-in operator/function can be planted; and (3) the tenant's ability to influence the connecting session's search_path. Limiting factors: this is authenticated (PR:L) - a purely external attacker with no database role cannot exploit it; it is most relevant in multi-tenant deployments where untrusted parties legitimately own databases, and is largely inert where only trusted operators hold DATABASE OWNER. No user interaction is required, and the trigger is passive (the operator's routine introspection query fires the payload).

The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H, base 9.4) is credible and internally consistent with the description: network-reachable PostgreSQL, low attacker privileges (a legitimate DATABASE OWNER / tenant role), no user interaction, and high impact on both the vulnerable database and subsequent systems (the postgres OS process and the Kubernetes pod's ServiceAccount token). The high subsequent-system impact (SC/SI/SA:H) is well-justified because exploitation escapes the database boundary into OS command execution and cluster-credential theft. No EPSS score, KEV listing, or POC was provided, so this is a high-severity issue by mechanism rather than a confirmed widespread-exploitation event - real-world risk is highest in multi-tenant CloudNativePG deployments where untrusted parties legitimately own databases; in single-tenant clusters where only trusted operators hold DATABASE OWNER, the practical exposure is lower. The PR:L requirement is a genuine limiting factor: an attacker must already hold DATABASE OWNER (or equivalent) on a managed database, so this is a tenant-escalation / lateral-movement flaw, not remote-unauthenticated RCE.

A tenant who holds DATABASE OWNER on a CloudNativePG-managed database sets a role- or database-level search_path pointing at the public schema and plants an overloaded operator/function there. When the instance-manager next runs an unqualified introspection query as the postgres superuser, the planted function executes with superuser rights, and the attacker chains COPY ... FROM PROGRAM to run OS commands in the pod and read the ServiceAccount token for further Kubernetes lateral movement. No public exploit identified at time of analysis, but the advisory and patch describe the technique in full detail.