CVE-2026-84199 in Kyverno
Summary
by MITRE • 09/01/2026
Kyverno before 1.16.2 contains a server-side request forgery (SSRF) vulnerability in the APICall feature. The URL field in a Policy's ServiceCall configuration is not validated, so a user with namespace-level Policy creation permissions can direct Kyverno to make HTTP requests to arbitrary internal resources (e.g., cloud metadata endpoints such as 169.254.169.254 or other tenants' resources). Because Kyverno executes these requests using its cluster-wide high-privilege ServiceAccount (a Confused Deputy problem), the responses—potentially including other tenants' secrets and cloud IAM credentials—are returned in the PolicyReport and can be read by the attacker, breaking multi-tenant isolation.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/01/2026
The vulnerability identified as a server-side request forgery within Kyverno versions prior to 1.16.2 represents a critical security flaw rooted in insufficient input validation of the APICall feature. This specific component allows policies to make HTTP requests during policy evaluation, but it fails to restrict or validate the target URLs specified by users. Consequently, an attacker with permissions to create namespace-level Policies can manipulate this functionality to force Kyverno to initiate connections to arbitrary internal resources. The lack of validation permits targeting sensitive infrastructure endpoints, such as cloud metadata services located at addresses like 169.254.169.254, or accessing resources belonging to other tenants within a multi-tenant Kubernetes environment. This flaw fundamentally undermines the integrity of network isolation mechanisms by allowing external actors to leverage internal systems for unauthorized data retrieval.
The operational impact is severe due to the execution context in which Kyverno operates. The vulnerability manifests as a classic Confused Deputy problem, where Kyverno executes these maliciously crafted requests using its cluster-wide high-privilege ServiceAccount rather than the identity of the user who created the policy. This elevation of privilege means that even if an attacker has limited permissions within a specific namespace, they can exploit Kyverno's elevated privileges to access sensitive data across the entire cluster. The responses from these forged requests are returned directly in the PolicyReport generated by Kyverno. Since this report is accessible to users with read permissions on policies or reports, the attacker can extract highly sensitive information, including secrets belonging to other tenants and cloud IAM credentials stored within metadata endpoints. This breach effectively breaks multi-tenant isolation, allowing lateral movement and data exfiltration that should have been contained.
From a classification perspective, this vulnerability aligns with CWE-918, which defines Server-Side Request Forgery (SSRF), specifically involving the lack of validation for user-supplied URLs. Furthermore, it maps to ATT&CK technique T1552.004, Unsecured Credentials: Cloud Instance Metadata API, as attackers can leverage this flaw to access cloud provider metadata services that often contain authentication tokens and configuration details. The scenario also reflects CWE-732, which pertains to incorrect permission assignment for privileged functions, given the misuse of a high-privilege service account by an unprivileged user through policy manipulation. These mappings highlight the severity of the issue in terms of both data exposure and privilege escalation within cloud-native environments.
To mitigate this risk, organizations must upgrade Kyverno to version 1.16.2 or later, where these validation checks have been implemented to prevent unauthorized external requests. In addition to upgrading, administrators should enforce strict network policies that restrict egress traffic from the Kyverno controller and webhook components to only allow connections to explicitly trusted internal services. Implementing least-privilege principles for ServiceAccounts is also critical; ensuring that the service account used by Kyverno does not possess unnecessary permissions can limit the damage if a similar vulnerability were discovered in the future. Regular auditing of policy configurations and monitoring for anomalous HTTP requests originating from Kyverno components can further enhance detection capabilities against such exploitation attempts.