CVE-2026-84196 in Kyverno
Summary
by MITRE • 09/01/2026
Kyverno before 1.18.0 contains a server-side request forgery vulnerability in apiCall.service.url that allows authenticated users to send arbitrary HTTP requests by injecting user-controlled input through variable substitution. Attackers can target internal services, cloud metadata endpoints, and loopback addresses, with response data reflected in admission error messages enabling non-blind data exfiltration.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/01/2026
The vulnerability identified in Kyverno versions prior to 1.18.0 represents a critical server-side request forgery flaw within the apiCall.service.url configuration parameter. This security defect arises from insufficient validation of user-supplied input during the variable substitution process, which is intended for dynamic policy evaluation but can be manipulated by authenticated users to redirect outbound HTTP requests. By injecting malicious payloads into variables used in Kyverno policies, an attacker can bypass expected network boundaries and force the Kyverno controller to initiate connections to arbitrary destinations controlled by the adversary. This mechanism effectively transforms a legitimate internal service feature into a vector for external interaction, undermining the isolation assumptions typically held within Kubernetes clusters where admission controllers are expected to operate strictly on local resources or trusted upstream registries without exposing themselves to internet-facing risks or internal lateral movement opportunities.
The operational impact of this vulnerability is severe due to its potential for non-blind data exfiltration and reconnaissance against internal infrastructure. Because Kyverno reflects the response from these forged requests directly into admission error messages, attackers can retrieve sensitive information such as cloud provider metadata credentials, internal service responses, or configuration details without needing a separate out-of-band channel. This capability allows adversaries to target loopback addresses like 127.0.0.1 to interact with local services that may not be exposed via network interfaces but are accessible through localhost connections from the pod running Kyverno. Furthermore, cloud metadata endpoints such as those found in AWS EC2 Instance Metadata Service or Azure Managed Identity endpoints become reachable, potentially leading to credential theft and further compromise of the underlying infrastructure. The ability to exfiltrate data directly into admission logs also means that this activity might blend with normal operational noise unless specifically monitored for anomalous patterns.
From a classification perspective, this vulnerability aligns closely with CWE-918 Server-Side Request Forgery (SSRF), which describes flaws where a web server fetches a remote resource without validating the user-supplied URL. Additionally, it maps to MITRE ATT&CK technique T1557 Adversary-in-the-Middle or more specifically T1046 Network Service Discovery when used for scanning internal services, and T1078 Valid Accounts if exploited by an authenticated insider threat actor leveraging legitimate credentials. The exploitation path involves the attacker crafting a Kyverno policy that utilizes variable substitution to construct a malicious URL pointing to an internal target. When this policy is applied or evaluated against resources in the cluster, the Kyverno webhook triggers the HTTP request and captures the response body, which is then returned as part of the admission decision error message visible to the user who submitted the resource.
Mitigation strategies must focus on immediate version upgrades and strict input validation practices. Organizations running affected versions should upgrade to Kyverno 1.18.0 or later where this issue has been addressed through enhanced URL parsing and restriction mechanisms that prevent access to internal IP ranges, loopback addresses, and known cloud metadata endpoints by default. In environments where upgrading is not immediately feasible, administrators can implement network policies to restrict egress traffic from the Kyverno controller pods, ensuring they cannot reach external or sensitive internal services except for explicitly whitelisted domains such as container registries required for image verification. Additionally, auditing admission webhook logs for unusual response patterns or large data volumes in error messages can help detect active exploitation attempts. It is also critical to enforce least-privilege access controls on Kyverno policies themselves, ensuring that only trusted administrators with high-level permissions can define complex variable substitutions and apiCall configurations within cluster-wide policies.