The Unpatched Kyverno SSRF Flaw That Turns Policies Into Cluster-Wide Backdoors

A critical security boundary in Kubernetes environments has been compromised. A new vulnerability note from CERT/CC has detailed a Server-Side Request Forgery (SSRF) flaw in Kyverno, the popular open-source, Kubernetes-native policy engine. Identified as CVE-2026-4789, the vulnerability affects Kyverno versions 1.16.0 to the present and allows attackers to bypass namespace restrictions to probe internal network services.

Kyverno is a cornerstone of cluster security, functioning as a dynamic admission controller that validates, mutates, and generates configurations. Because it must intercept and modify API requests, it naturally operates with “high-level permissions,” making it a “critical component of the cluster’s security posture and trust boundary”.

The flaw resides in Kyverno’s CEL-based HTTP functions (specifically Get and Post). According to the vulnerability note:

“Unlike Kyverno’s resource library, which enforces namespace boundaries, the HTTP library at pkg/cel/libs/http/http.go performs no URL validation or scoping”.

With “no blocklists, namespace restrictions, or destination checks” in place, an attacker can use these policies to “issue arbitrary HTTP requests from the Kyverno admission controller pod”.

The impact of this SSRF is particularly severe because of where the requests originate. An attacker with only “namespace-level permissions” can create a malicious policy that triggers an internal HTTP request, captures the response, and exfiltrates the data through the policy’s own error messages.

Because the Kyverno admission controller “often has privileged network reachability across internal cluster services and cloud metadata APIs,” this flaw effectively allows for:

• Cross-namespace data access.Exposure of sensitive metadata from cloud providers.
• Unauthorized access to internal cluster services that would otherwise be shielded.

CERT/CC noted that they were “unable to reach the vendor to coordinate this vulnerability,” meaning a patch is currently unavailable.

Until an official fix is released, administrators are urged to implement the following mitigation strategies:

• Destination Controls: Implement strict URL validation within the CEL HTTP library to block access to “link-local and cloud metadata address ranges”.
• Allowlists: Limit outbound requests to only “approved in-cluster services”.
• Network Policies: Apply “default deny network policies” to the Kyverno admission controller pod itself to prevent unauthorized egress.

Without these safeguards, the very tool meant to enforce Pod Security Standards could become the primary engine for a cluster-wide breach.