CVE-2026-4789: 
Wolfi vulnerability analysis and mitigation

CVE-2026-4789 is a Server-Side Request Forgery (SSRF) vulnerability in Kyverno, the Kubernetes-native policy engine, affecting versions 1.16.0 through 1.17.1. The flaw exists in Kyverno's CEL-based HTTP library (pkg/cel/libs/http/http.go), where the http.Get() and http.Post() functions perform no URL validation or namespace scoping, allowing namespaced policies to trigger arbitrary internal HTTP requests from the Kyverno admission controller pod. It was publicly disclosed on March 30, 2026, with a patch released in version 1.17.0. The vulnerability carries a CVSS v3.1 base score of 9.8 (Critical) as assessed by CISA-ADP (CERT/CC Advisory, GitHub Advisory).

The root cause is CWE-918 (Server-Side Request Forgery): the CEL HTTP library at pkg/cel/libs/http/http.go implements http.Get() and http.Post() functions without any URL blocklist, namespace restrictions, or destination validation. In contrast, Kyverno's resource library (pkg/cel/libs/resource/lib.go) correctly enforces namespace boundaries. An attacker with only namespace-scoped permissions to create policies in the policies.kyverno.io API group can craft a NamespacedValidatingPolicy that calls http.Get() with an arbitrary internal URL; the response is captured in a CEL variable and exfiltrated via the policy's messageExpression field returned in the admission denial response. A complete proof-of-concept was developed and tested on Kyverno v1.16.2 (Helm chart 3.6.2) on Kubernetes v1.35.0 (GitHub Advisory, CERT/CC Advisory).

Because requests originate from the Kyverno admission controller — which typically has privileged network reachability across all cluster namespaces and cloud metadata APIs — a successful exploit enables cross-namespace data access, exposure of cloud instance metadata (e.g., AWS/GCP/Azure metadata at 169.254.169.254), and exfiltration of sensitive service responses via policy error messages. This effectively breaks Kyverno's intended namespace isolation security boundary, potentially allowing an attacker with limited namespace permissions to escalate access to cluster-wide secrets, credentials, or internal APIs. The integrity and availability impacts are also rated high, as the attacker could potentially interact with internal services in unintended ways (CERT/CC Advisory, GitHub Advisory, Orca Security Blog).

A public proof-of-concept exploit script was developed and tested by Igor Stepansky from Orca Security Research Pod, though as of the disclosure date there is no evidence of active in-the-wild exploitation (CERT/CC Advisory, Orca Security Blog). The vulnerability requires the attacker to have namespace-scoped policy creation permissions in the policies.kyverno.io API group, which is the default configuration for Kyverno 1.16.0+. The EPSS score is approximately 0.005% (very low probability of exploitation in the near term). The vulnerability is not currently listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Attribution is to Orca Security for responsible disclosure (CERT/CC Advisory).

1. Reconnaissance: Identify a Kubernetes cluster running Kyverno versions 1.16.0–1.17.1 with the policies.kyverno.io CRDs enabled (the default). Confirm namespace-scoped policy creation permissions are available to the attacker account.
2. Setup attacker namespace: Create an attacker-controlled namespace and service account with namespace-scoped permissions: kubectl create namespace attacker-ns && kubectl create serviceaccount namespace-admin -n attacker-ns.
3. Craft malicious NamespacedValidatingPolicy: Write a NamespacedValidatingPolicy resource that uses the CEL http.Get() function to send a request to a target internal URL (e.g., http://169.254.169.254/latest/meta-data/ for cloud metadata, or an internal service endpoint like http://internal-service.other-namespace.svc.cluster.local).
4. Exfiltrate response via messageExpression: Configure the policy's messageExpression field to embed the HTTP response body in the admission denial message, so the response is returned to the attacker when the policy triggers.
5. Apply the policy and trigger evaluation: Apply the malicious policy to the cluster (kubectl apply -f malicious-policy.yaml) and trigger an admission event (e.g., create a pod in the attacker namespace) to cause Kyverno to evaluate the policy and issue the HTTP request.
6. Collect exfiltrated data: Read the admission denial error message returned by Kyverno, which contains the response from the internal target URL, effectively exfiltrating sensitive data across namespace boundaries (GitHub Advisory, CERT/CC Advisory).

• Network: Unexpected outbound HTTP/HTTPS requests from the Kyverno admission controller pod to internal cluster services, other namespaces' service endpoints, or cloud metadata IPs (e.g., 169.254.169.254); unusual egress traffic patterns from the kyverno namespace.
• Logs: Kyverno admission controller logs showing HTTP requests to unexpected internal URLs during policy evaluation; admission denial messages containing embedded HTTP response bodies or internal service data in the messageExpression output.
• Kubernetes API: Presence of NamespacedValidatingPolicy resources in non-administrative namespaces that reference http.Get() or http.Post() CEL functions with arbitrary or internal URLs; policy creation events by low-privileged service accounts in audit logs.
• Process/Pod: Unusual network connections originating from the Kyverno admission controller pod (kyverno-admission-controller-*) to services outside its expected communication scope (CERT/CC Advisory, GitHub Advisory).

The primary remediation is to upgrade Kyverno to version 1.17.0 or later, which includes fixes for the unrestricted CEL HTTP functions (GitHub Advisory). The CNCF announced Kyverno 1.18 as a subsequent release with additional improvements (CNCF Blog). As interim workarounds: (1) apply default-deny NetworkPolicy resources to the Kyverno admission controller pod to restrict unauthorized egress; (2) use RBAC to restrict who can create NamespacedValidatingPolicy resources in the policies.kyverno.io API group; (3) review existing CEL policies for use of http.Get() or http.Post() functions and restrict them to trusted sources only; (4) implement firewall rules blocking outbound connections from Kyverno to link-local and cloud metadata address ranges (CERT/CC Advisory).

The vulnerability was discovered and responsibly disclosed by Igor Stepansky from Orca Security Research Pod, who published a detailed technical blog post explaining how the flaw breaks Kubernetes namespace isolation (Orca Security Blog). CERT/CC coordinated the disclosure and noted they were unable to reach the Kyverno vendor prior to publication, resulting in the advisory being published without a vendor statement (CERT/CC Advisory). The vulnerability was mentioned in The Hacker News weekly security recap, indicating moderate industry attention (The Hacker News). The GitHub advisory was initially published as a duplicate (GHSA-qqrv-2hch-83q4) and later consolidated into the canonical advisory GHSA-rggm-jjmc-3394 on April 14, 2026.