Summary
| Parameter | Value |
|---|---|
| CVE ID | CVE-2026-84200 |
| Alert Source | GitHub Advisory - Critical Vulnerability |
| CVE Publication Year | 2026 |
| Date Published | 2026-09-01 |
| Vendor | Kyverno |
| Product | Kyverno |
| CVSS Score | 9.0 (critical) |
| EPSS Score | No data |
| CISA KEV | No |
| Ransomware | Not confirmed |
Vulnerability Description
Kyverno versions v1.9.0 through v1.12.7 contain a flaw in policy exception handling.
When a policy in enforce mode is combined with two PolicyException objects, the less restrictive exception takes precedence. An attacker can exploit this by crafting a resource name matching the second exception’s name pattern (for example *ingress*), bypassing the policy - including one that blocks hostPath volumes.
The consequence goes beyond bypassing a single rule. Kyverno acts as an admission controller - the mechanism enforcing security rules for everything entering Kubernetes. A policy blocking hostPath prevents container escape to the node; bypassing it means a user with pod-creation rights can mount the host filesystem.
A separate problem is that this vulnerability produces no error signal. The policy still shows as active and enforced in the cluster, and compliance reporting shows the expected state. Fixed in v1.13.0.
Required Actions
- Upgrade Kyverno to v1.13.0 or later. Check the controller version actually running in the cluster (
kubectl -n kyverno get deploy -o wide) rather than the version declared in the Helm repository - in GitOps-managed environments the two diverge. - Inventory PolicyException objects (
kubectl get polex -A). Identify policies with more than one exception attached - precisely the configuration that triggers the flaw. - Review name patterns in exceptions. Wildcard patterns (
*ingress*,*-system-*) are overly broad and can be matched by a deliberately chosen resource name. Replace them with explicit resource names or label selectors. - Check whether the cluster runs pods with
hostPathvolumes that policy should have blocked - the simplest test of whether the bypass has already been used. - Restrict permission to create PolicyException objects. The ability to add an exception is equivalent to the ability to disable a policy; grant it only to the platform security team.
- Do not treat the Kyverno compliance report as evidence. Until you patch, confirm enforcement empirically - by attempting to create a resource that should be rejected.
Who Is Affected?
Organisations running Kyverno v1.9.0 - v1.12.7 as an admission controller in Kubernetes clusters with enforce-mode policies alongside PolicyException objects.
Kyverno is most often found in platform teams at banks, telecommunications operators and retailers that built an internal container platform and needed a tool to enforce security standards - particularly after PodSecurityPolicy was removed. It also increasingly appears in DORA and NIS2 contexts as technical evidence of configuration control.
Clusters with no PolicyException objects are not exposed to this specific flaw, but the affected version range spans releases several years old - confirm the controller’s actual version rather than assuming it is current.
Sources
Need help securing your systems? nFlo team offers vulnerability management and 24/7 SOC services. Contact us.
