CVE-2026-100705 in Kyverno
Summary
by MITRE • 09/26/2026
Kyverno before 1.19.1 is vulnerable to server-side request forgery. The default egress blocklist (169.254.169.254, 169.254.169.253, metadata.google.internal, 127.0.0.0/8, ::1/128) and the scoped-token control were wired only into the new CEL http.Get/Post library and were never applied to the legacy apiCall service executor (pkg/engine/apicall/executor.go) or to the GlobalContextEntry external-API path, which handle every non-CEL context[].apiCall.service call. Because these paths use a plain net/http client with no egress filtering and no validation of the configured service URL, a ClusterPolicy or GlobalContextEntry author — or, where a deployed policy templates the service URL from the admission resource, a lower-privileged resource submitter — can cause Kyverno to issue GET/POST requests to an arbitrary host, including the cloud metadata endpoint, loopback, and any in-cluster service, reading cloud instance credentials and reaching internal endpoints with Kyverno's network position. The executor also unconditionally attaches Kyverno's projected ServiceAccount token to the attacker-chosen destination; the token is audience-scoped, limiting its replay value. Fixed in 1.19.1.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/26/2026
Kyverno versions prior to 1.19.1 contain a critical server-side request forgery vulnerability that allows attackers to exploit misconfigured policy definitions or resource submissions to initiate unauthorized network requests from the Kyverno controller pod. The root cause of this flaw lies in an inconsistency within how egress filtering and authentication controls are applied across different execution paths for external API calls. While newer CEL-based HTTP libraries correctly implement strict egress blocklists and scoped token validation, these security measures were inadvertently omitted from the legacy apiCall service executor located at pkg/engine/apicall/executor.go and the GlobalContextEntry external-API path. These older components handle all non-CEL context.apiCall.service invocations but rely on a plain net/http client that lacks any egress filtering or URL validation logic, creating a significant security gap in the policy evaluation engine.
The operational impact of this vulnerability is severe because it enables privilege escalation through resource submission rather than direct access to Kyverno itself. A ClusterPolicy author can define policies with hardcoded malicious URLs, but more dangerously, if a deployed policy template dynamically constructs service URLs from fields within admission resources, any lower-privileged user who submits such resources can trigger arbitrary outbound requests on behalf of the Kyverno controller. This effectively bypasses network segmentation and internal access controls because the request originates from Kyverno’s privileged pod identity. Attackers can leverage this to reach cloud metadata endpoints like 169.254.169.253 or 169.254.169.254, potentially exfiltrating instance credentials and compromising the underlying infrastructure. Additionally, internal cluster services accessible only from within the pod network can be reached, allowing for further lateral movement or data theft.
A critical aspect of this vulnerability is the unconditional attachment of Kyverno’s projected ServiceAccount token to every outgoing request made through these vulnerable paths. Although the token is audience-scoped which limits its immediate replay value across different services, it still provides a valid authentication context that can be exploited against internal APIs expecting Kubernetes service account tokens. This allows attackers to interact with backend systems as if they were Kyverno itself, potentially modifying configurations or accessing sensitive data protected by RBAC policies that trust the Kyverno service account identity. The combination of unrestricted egress and automatic credential injection transforms a simple policy definition into a powerful attack vector for network pivoting and cloud metadata theft.
This vulnerability aligns with CWE-918 Server-Side Request Forgery (SSRF) as it allows an attacker to influence the server to make requests to arbitrary destinations. It also maps to MITRE ATT&CK techniques involving Cloud Metadata API Access, specifically T1528, where attackers target cloud instance metadata services to steal credentials and configuration data. The exploitation path often involves crafting malicious admission resources or policy templates that trigger these vulnerable code paths during the validation or mutation process of Kubernetes objects.
To mitigate this risk, organizations must immediately upgrade Kyverno to version 1.19.1 or later where the egress blocklist and scoped-token controls are consistently applied across all execution engines including the legacy apiCall executor. Until an upgrade is possible, administrators should audit existing ClusterPolicies for any dynamic URL construction based on user-controlled input and restrict such patterns. Additionally, implementing network policies to limit outbound traffic from Kyverno pods can provide a defensive layer by blocking access to cloud metadata endpoints and other sensitive internal services regardless of the application-level flaws. Regular review of policy templates ensures that no lower-privileged users can inadvertently or maliciously trigger unauthorized external requests through context API calls.