The vulnerability in CloudNativePG isn't really about search_path configuration—it's about a fundamental architectural misjudgment: the developers treated introspection queries as infrastructure code operating in a trusted context, when in fact those queries execute as postgres superuser inside a security domain where DATABASE OWNER already holds powerful, underappreciated capabilities.
The attack works because PostgreSQL permits operator overloading in the public schema. When you grant DATABASE OWNER to an untrusted principal, that principal can overload built-in operators like '>' with custom functions. CloudNativePG's instance-manager runs introspection queries—SELECT COUNT(*) FROM pg_extension, and similar—as the postgres superuser. If those queries implicitly resolve the '>' operator through search_path, they invoke whatever function DATABASE OWNER installed. This isn't a code bug being exploited; it's using PostgreSQL's documented extension mechanism as an attack primitive against a connection pool that never expected to encounter it.
The escalation path from here is severe. Superuser access enables COPY ... FROM PROGRAM, which executes commands as the PostgreSQL OS user. In a Kubernetes context, that user can read the pod's ServiceAccount token from the filesystem, pivoting from database compromise to cluster-level access. No zero-day, no misconfiguration beyond granting DATABASE OWNER, no deviation from documented PostgreSQL behavior.
What should you check: verify that CloudNativePG connections to managed databases explicitly set search_path to pg_catalog before issuing any introspection query, and confirm that DATABASE OWNER privileges are not granted to any principal you do not fully trust with superuser-equivalent capabilities. The fix—pinning search_path—corrects the symptom but acknowledges that the original threat model treated DATABASE OWNER as 'low privilege' when the role actually has significant attack surface against any superuser connection that doesn't isolate its operator resolution context. This pattern has appeared in multiple PostgreSQL tooling CVE disclosures over the years; the architectural flaw is in how PostgreSQL tooling has historically been written, not just in this deployment.