CVE-2026-84195 in Kyverno
Summary
by MITRE • 09/01/2026
Kyverno before 1.16.4 automatically attaches the admission controller's ServiceAccount token to outbound HTTP requests in apiCall service mode without explicit authorization headers. Attackers can exfiltrate the token by directing apiCall requests to external or attacker-controlled endpoints, gaining full control over Kyverno policies and cluster resources.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/01/2026
The vulnerability identified involves a critical flaw in the handling of authentication credentials within the Kyverno admission controller prior to version 1.16.4. Specifically, when operating in apiCall service mode, the system automatically attaches the Kubernetes ServiceAccount token associated with its own identity to all outbound HTTP requests initiated by the policy engine. This behavior occurs without requiring explicit authorization headers or any form of user-defined configuration that would restrict credential usage. The underlying technical flaw stems from an overly permissive implementation where the default client transport is configured to inject bearer tokens into every outgoing request, assuming a trusted internal network environment and ignoring potential external destinations defined in policy rules.
This design decision creates a significant security risk because it allows for token exfiltration through maliciously crafted policies or compromised rule definitions. An attacker who gains write access to Kyverno ClusterPolicy resources can define an apiCall action that targets an endpoint under their control, such as an external web server or logging service they operate. When the admission controller processes a request and triggers this policy, it will automatically include its ServiceAccount token in the HTTP headers of the outbound call. Since Kubernetes tokens are often long-lived and carry high privileges depending on the bound RoleBindings, capturing these tokens provides the attacker with valid authentication credentials for the cluster API server.
The operational impact of this vulnerability is severe, as possession of a privileged ServiceAccount token effectively grants full control over Kyverno policies and potentially broader cluster resources if the account has elevated permissions. The attacker can use the stolen token to authenticate directly against the Kubernetes API, bypassing admission controls entirely. This enables them to create new policies that further entrench their access, modify existing security rules to allow malicious workloads, or escalate privileges by binding additional roles to the compromised service account. In environments where Kyverno is deployed with cluster-admin level permissions for its own ServiceAccount, this vulnerability represents a complete compromise of the cluster's integrity and availability.
From an industry standards perspective, this flaw aligns closely with CWE-798: Use of Hard-coded Credentials, as it involves the automatic inclusion of sensitive authentication material in contexts where it should be restricted or explicitly authorized. It also relates to CWE-200: Information Exposure, specifically regarding the leakage of credentials through network traffic that may traverse untrusted networks if external endpoints are targeted. In terms of MITRE ATT&CK techniques, this vulnerability facilitates Credential Access via T1552.004: Unsecured Credentials in Cloud Infrastructure and enables subsequent lateral movement or privilege escalation steps such as T1098.003: SSH Authorized Keys Modification or T1648: Elevate with Enterprise Permission Grants if the token has sufficient rights.
Mitigation strategies must focus on immediate version upgrades and configuration hardening. The primary remediation is to upgrade Kyverno to version 1.16.4 or later, where this automatic attachment behavior has been addressed through stricter controls over credential injection in outbound requests. For environments that cannot immediately patch, administrators should audit all ClusterPolicy resources for apiCall actions targeting external URLs and restrict these policies to only allow communication with trusted internal services using network policies or egress rules at the cluster level. Additionally, ensuring that Kyverno's ServiceAccount has minimal necessary permissions reduces the blast radius if a token is compromised. Implementing strict RBAC policies and regularly rotating service account tokens can further limit the window of opportunity for attackers exploiting this vulnerability.