Recently a new critical 10.0/10 (CVSS 3.1, which might score lower with CVSS 4.0 calculation method) vulnerability was disclosed in the Kyverno project, a widely-adopted Kubernetes-native policy engine designed for platform engineering teams.
This authorization bypass vulnerability allows authenticated users with namespaced Policy permissions to access and mutate resources in different namespaces across the entire cluster, completely breaking Kubernetes namespace isolation, a fundamental security boundary in multi-tenant environments.
In this post, we will demonstrate an example of how this cloud-native vulnerability can be used to perform cross-namespace data exfiltration.
Kyverno is a widely adopted Cloud Native Computing Foundation (CNCF) project that serves as a cloud native policy engine. It allows platform engineers to automate security and compliance. One of its features is to serve as a Kubernetes dynamic admission controller, allowing it to enforce security policies, compliance rules, and best practices across their Kubernetes clusters without requiring a new language or complex configuration.
Kyverno is deployed as a set of Pods in the cluster, typically in the kyverno namespace, and uses ValidatingAdmissionWebhook and MutatingAdmissionWebhook configurations to intercept API server requests.
When a resource is created or modified, the Kubernetes API server (kube-apiserver),calls Kyverno’s webhook service, which evaluates the resource against active policies and returns an allow/deny decision.
Kyverno operates as a critical security boundary in Kubernetes clusters. As an admission controller, it sits between users and the API server, with powerful RBAC permissions (Role-Based Access Control) necessary to inspect and modify resources across all namespaces.
CVE-2026-22039 is an authorization boundary bypass in Kyverno’s Policy apiCall context feature. The vulnerability exists in how Kyverno handles API calls specified in policy context entries. Specifically, the code does not validate that the policy author should have access to the requested resource in the specified namespace.
The apiCall.go’s vulnerable Fetch function performs variable substitution, including user-controlled annotations, into the urlPath field. The resolved urlPath is then executed using Kyverno’s admission controller ServiceAccount, which has broad cluster-wide RBAC permissions.
This means that any authenticated user with permission to create a namespaced Policy can cause Kyverno to perform Kubernetes API requests using Kyverno’s own identity.
To demonstrate how the vulnerability is actually working, lets do the following:
attacker-restricted-namespace’ namespace.kubectl auth can-i get configmaps -n kube-system \ --as=system:serviceaccount:attacker-restricted-namesapce:attacker-sa
Lets create a target configmap in the kube-system namespace, containing a secret key:
Now the attacker creates and applies a malicious-policy.yaml inside the ‘attacker-restricted-namespace’, exploiting the vulnerability in Kyverno’s apiCall that we explained earlier. Pay attention to the always deny message as an exfiltration channel:
Now the attacker needs to create a trigger for the vulnerability to actually work, and creates the following trigger-configmap.yaml in the ‘attacker-restricted-namespace’, which is pointing to the target namespace, kube-system, and the target resource, target-cm, using annotations:
The attacker triggers active malicious-policy.yaml using the trigger-configmap.yaml utilizing his own attacker-sa ServiceAccount:
trigger-configmap.yaml.kube-apiserver authenticates and authorizes the request to create trigger-configmap in ‘attacker-restricted-namespace’ (utilizing attacker ServiceAccount).kube-apiserver calls Kyverno webhook service.apiCall urlPath. The resolved urlPath value is now : /api/v1/namespace/kube-system/configmaps/target-cm.kube-system namespace, which is returned to the attacker.
One might wonder whether the attacker needs prior knowledge of the resources names in the target namespaces. However, this concern is easily addressed using the same exploitation technique by crafting a reconnaissance policy with a different ‘urlPath’. For example, the same policy can be used for all ConfigMaps enumeration in the kube-system namespace:
Low complexity and high flexibility of the exploitation, combined with reconnaissance capability, underscore the high impact of this vulnerability, which is not only limited to cross-namespace data exfiltration. The scope of the vulnerability depends on the Kyverno ServiceAccount RBAC permissions. To help the reader understand the scope and impact please run:
kubectl auth can-i --as=system:serviceaccount:kyverno:kyverno-admission-controller --list
This vulnerability demonstrates a pure cloud-native security challenge where the vulnerable component is not a CVE in a third-party artifact that is shipped with the application, but rather a flaw in the application logic itself.
At Minimus, we continuously monitor not only dependency-level vulnerabilities, but also flaws in application logic that impact the runtime behavior of cloud-native applications. We deliver fixed image versions as soon as patches are available, so customers benefit from both minimized images that reduce software supply chain attack surface and timely, proactive security updates. This is why our Kyverno images were updated shortly after the upstream fix was released. Try Minimus today to reduce CVE noise, ship hardened images faster, and stay ahead of emerging vulnerabilities.
.svg)
.svg)
.svg)
.svg)
