CVE-2026-122305 in Kyverno
Summary
by MITRE • 11/05/2026
Kyverno before 1.19.2 contains a denial of service vulnerability in substituteVariablesIfAny that allows low-privileged users to hang the admission webhook via self-referential variable templates. Attackers can create resources whose annotations re-introduce the embedded policy variable, causing unbounded substitution loops that exhaust CPU and memory and block cluster-wide admission.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 11/05/2026
The vulnerability identified in Kyverno versions prior to 1.19.2 represents a critical denial of service flaw within the substituteVariablesIfAny function, which is responsible for processing dynamic variables during policy evaluation. This issue specifically impacts low-privileged users who possess permissions to create or modify resources that trigger admission webhooks. By crafting specific resource annotations, an attacker can embed self-referential variable templates into the metadata of these objects. When Kyverno processes these resources, it attempts to resolve and substitute the embedded variables as part of its standard policy enforcement workflow. However, because the template references itself directly or indirectly through a chain of dependencies within the annotation structure, the substitution engine enters an infinite loop. This unbounded recursion prevents the function from terminating normally, leading to immediate resource exhaustion on the node hosting the Kyverno controller manager.
From a technical perspective, this flaw exploits the lack of depth limits or cycle detection mechanisms in the variable substitution logic before version 1.19.2. The admission webhook operates synchronously for certain policy types, meaning that when it receives a request containing such malicious annotations, it must complete the entire evaluation process before responding to the Kubernetes API server. Since the loop is infinite, the webhook never returns a response, causing the HTTP connection to hang indefinitely. This behavior effectively blocks the thread handling the admission decision and consumes significant CPU cycles as the system attempts endless string manipulations and memory allocations for each iteration of the substitution attempt. The result is not merely a localized failure but a cluster-wide impact because the blocking of this critical webhook can stall incoming requests from other legitimate users, leading to a widespread denial of service condition across the entire Kubernetes cluster.
The operational impact of this vulnerability extends beyond simple resource exhaustion. Because Kyverno serves as an admission controller for many organizations' security policies, its unavailability or severe degradation compromises the integrity and safety mechanisms of the cluster. Legitimate workloads may fail to start if they require policy validation that is blocked by the hung webhook. Furthermore, the high CPU usage generated by these loops can degrade performance on shared nodes, affecting other critical system components running in the same environment. This scenario aligns with CWE-400, which describes uncontrolled resource consumption, and specifically relates to infinite loop conditions often categorized under CWE-835 if viewed through the lens of logic errors leading to denial of service. In terms of offensive security frameworks such as MITRE ATT&CK for Kubernetes, this technique maps closely to T1496 Resource Hijacking or potentially T1055 Process Injection depending on how deeply the attacker can escalate privileges after achieving initial access via low-privileged accounts.
Mitigation strategies primarily involve upgrading Kyverno to version 1.19.2 or later, where these self-referential loops are detected and handled gracefully without causing unbounded execution. Until an upgrade is feasible, administrators should implement strict network policies to restrict access to the admission webhook endpoints from non-essential services and users. Additionally, enforcing least privilege principles ensures that only highly trusted service accounts have permissions to create or modify resources with complex annotations that trigger policy evaluation. Monitoring tools should be configured to alert on unusually high CPU usage in Kyverno pods or prolonged latency in API server responses related to admission webhooks. Regular audits of resource definitions and the implementation of input validation at the application level can further reduce the attack surface by preventing malformed or recursive variable structures from reaching the Kyverno engine in the first place.