Kyverno EUVD-2026-87676

Requires a multi-tenant Kubernetes cluster running Kyverno 1.16.0-1.19.0 where the attacker holds RBAC permission to create a namespaced policy object (NamespacedValidatingPolicy, or the namespaced mutating, deleting, generating, or image-validating policy kinds) in a namespace they control. A cluster-scoped GlobalContextEntry must exist and cache data from namespaces the tenant cannot read via RBAC - that cached data is the disclosed asset; with no GlobalContextEntry configured there is nothing to leak. No user interaction and no admission-time validation stands in the way, but the flaw is inert on single-tenant clusters or clusters that do not use GlobalContextEntry.

This is a genuine multi-tenant confidentiality boundary breach, not a high-CVSS-but-low-real-risk issue, though its blast radius is bounded by preconditions. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N, score 8.3) is internally consistent with the description: network-reachable Kubernetes API, low complexity, low privilege (a tenant able to create namespaced policies), no user interaction, high confidentiality impact to the vulnerable system and - importantly - high subsequent-system confidentiality impact (SC:H) reflecting that data belonging to OTHER namespaces/tenants is exposed. There is a mild internal tension in that VC:H and SC:H both being High may double-count a single read primitive, but it correctly captures a scope/authorization-boundary crossing. No EPSS score, no CISA KEV listing, and no public exploit code are provided, so exploitation status is 'no public exploit identified at time of analysis' - the risk is derived from the mechanism (a trivially-invoked CEL call once a policy can be authored) rather than observed attacks. The realism of exploitation depends entirely on two deployment facts not guaranteed by the CVE: that the cluster is multi-tenant with delegated namespaced-policy creation, and that a cluster-scoped GlobalContextEntry actually caches sensitive cross-namespace data. Where both hold, this is a real priority for cluster operators; where the cluster is single-tenant or does not use GlobalContextEntry, real risk is low.

In a multi-tenant Kubernetes cluster, a tenant granted RBAC to create namespaced Kyverno policies (e.g. NamespacedValidatingPolicy) in their own namespace authors a policy whose CEL expression calls globalContext.get("<entry>", ""). Because globalcontext.Lib is registered without namespace confinement, the call returns the full cached contents of a cluster-scoped GlobalContextEntry - including data cached from namespaces the tenant has no RBAC permission to read - with no admission control rejecting the request. No public exploit code is identified, but the technique requires only writing a valid policy manifest, so exploitation complexity is low.