CVE-2026-100703: 
Kyverno Analyse et atténuation des vulnérabilités

CVE-2026-100703 is an authorization bypass vulnerability in Kyverno, a Kubernetes-native policy engine, that allows authenticated tenants to read cross-namespace cached data by exploiting an unconfined CEL library registration. Specifically, the globalcontext.Lib CEL library is registered in the policy environment without being bound to the policy's namespace, unlike sibling libraries (resource.Lib, http.Lib, configMap loader). Affected versions are Kyverno 1.16.0 through 1.19.0; the issue is fixed in 1.19.1. It carries a CVSS v3.1 score of 7.7 (High) and a CVSS v4.0 score of 8.3 (High) (GitHub Advisory, Kyverno Advisory).

The root cause is CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor): globalcontext.Lib is registered in pkg/cel/policies/vpol/compiler/compiler.go without passing a namespace argument, while sibling libraries explicitly receive the policy's namespace to confine their data access scope. A tenant with permission to create any namespaced policy kind (NamespacedValidatingPolicy, NamespacedMutatingPolicy, NamespacedDeletingPolicy, NamespacedGeneratingPolicy, or NamespacedImageValidatingPolicy) can craft a policy that calls globalContext.get("<entry>", ""), which returns the full cached contents of a cluster-scoped GlobalContextEntry — including data from namespaces the tenant has no RBAC rights to read. No admission validation exists to reject such calls. The vulnerability is exploitable over the network with low privileges and no user interaction required, and is part of a recurring pattern previously fixed in apiCall.URLPath (GHSA-8p9x-46gm-qfx2), the ConfigMap loader (GHSA-cvq5-hhx3-f99p), and CEL http.Lib (GHSA-rggm-jjmc-3394) (Kyverno Advisory).

Any authenticated tenant with the ability to create namespaced policies in their own namespace can read the full cached contents of cluster-scoped GlobalContextEntry objects, which may include data from all namespaces across the cluster — regardless of their RBAC permissions. The confidentiality impact is high, as sensitive Kubernetes resources or API call results cached cluster-wide (e.g., secrets metadata, configuration data, or arbitrary API responses) can be disclosed to unauthorized tenants. There is no integrity or availability impact, but the data exposure can facilitate lateral movement or privilege escalation by revealing information about other tenants' namespaces (Kyverno Advisory, GitHub Advisory).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation at the time of disclosure. The EPSS score is 0.0, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. However, exploitation requires only low privileges (the ability to create a namespaced policy in one's own namespace) and no user interaction, making it straightforward for any tenant in a multi-tenant Kyverno deployment. The vulnerability is only exploitable if at least one GlobalContextEntry exists with cached data spanning multiple namespaces (Kyverno Advisory, GitHub Advisory).

1. Reconnaissance: Confirm the target Kyverno cluster is running version 1.16.0–1.19.0 and that at least one cluster-scoped GlobalContextEntry exists with cached data spanning multiple namespaces (e.g., kubectl get globalcontextentries -A).
2. Obtain namespace access: Ensure you have RBAC permission to create a namespaced policy kind (e.g., NamespacedValidatingPolicy) in your own namespace — this is the only privilege required.
3. Craft a malicious policy: Author a NamespacedValidatingPolicy (or any other namespaced policy kind) that includes a CEL expression calling globalContext.get("<target-entry-name>", "") to retrieve the full cached contents of the target GlobalContextEntry.
4. Submit the policy: Apply the crafted policy to your namespace using kubectl apply -f malicious-policy.yaml. No admission validation will reject the globalContext.get() call.
5. Trigger policy evaluation: Cause the policy to be evaluated (e.g., by creating or updating a resource in your namespace that matches the policy's match criteria).
6. Exfiltrate data: Observe the policy evaluation results or use the CEL expression output to extract cross-namespace cached data — including resources from namespaces you have no RBAC permission to read directly (Kyverno Advisory).

• Kubernetes Audit Logs: Creation of NamespacedValidatingPolicy, NamespacedMutatingPolicy, NamespacedDeletingPolicy, NamespacedGeneratingPolicy, or NamespacedImageValidatingPolicy resources by low-privileged tenant accounts, especially those containing globalContext.get() in their CEL expressions.
• Kyverno Logs: Policy evaluation events referencing GlobalContextEntry objects from namespaces not associated with the policy author's namespace; unexpected access patterns to cluster-scoped GlobalContextEntry resources.
• Kubernetes API Audit Logs: GET or LIST requests to globalcontextentries resources from service accounts or users that do not normally interact with cluster-scoped resources.
• Policy Content: Presence of globalContext.get("<entry>", "") calls in namespaced policy definitions authored by non-administrative tenants.

Upgrade Kyverno to version 1.19.1 or later, which fixes the issue by properly confining globalcontext.Lib to the policy's namespace. If an immediate upgrade is not possible, restrict the ability to create namespaced policy kinds (NamespacedValidatingPolicy and siblings) to trusted users only via RBAC, preventing untrusted tenants from authoring policies that could exploit this flaw. Additionally, review all existing GlobalContextEntry resources for sensitivity and avoid caching data that spans namespaces containing sensitive information until the patch is applied (Kyverno Advisory, GitHub Advisory).

The vulnerability was discovered and reported by Brian Willows (graith.co.uk) with AI assistance (Claude), who noted it is the fourth instance of the same pattern in Kyverno — a context source reachable from a namespaced policy without namespace confinement — following prior fixes for apiCall.URLPath, the ConfigMap loader, and CEL http.Lib. The reporter suggested a systemic fix: a single chokepoint that refuses to construct a namespaced policy environment unless every registered library has been given a namespace, to prevent future recurrences of this vulnerability class (Kyverno Advisory).