CVE-2026-100703 in Kyverno
Summary
by MITRE • 09/26/2026
Kyverno 1.16.0 through 1.19.0 registers the globalcontext.Lib CEL library in its policy environment without confining it to the policy's namespace, unlike the sibling libraries (resource.Lib, http.Lib, configMap loader) which are handed the policy namespace. A tenant who can create a namespaced policy (e.g. NamespacedValidatingPolicy, and likewise the namespaced mutating, deleting, generating, and image-validating policy kinds) in their own namespace can call globalContext.get("<entry>", "") and receive the full cached contents of a cluster-scoped GlobalContextEntry, including data cached from namespaces the tenant has no RBAC permission to read. No admission validation rejects such calls. Fixed in 1.19.1.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/26/2026
The vulnerability identified in Kyverno versions 1.16.0 through 1.19.0 represents a critical namespace isolation failure within the policy evaluation engine, specifically concerning the handling of global context data via Common Expression Language libraries. Kyverno is a Kubernetes-native policy management tool that allows administrators to define policies for validating and mutating resources. In this flawed implementation, the globalcontext.Lib CEL library was registered in the policy environment without being confined to the specific namespace of the executing policy. This stands in direct contrast to other sibling libraries such as resource.Lib, http.Lib, and configMap loader, which are correctly scoped to operate within the boundaries of the policy's designated namespace. The architectural inconsistency creates a significant security gap where tenant users with permissions to create namespaced policies can bypass intended access controls by invoking globalContext.get("", ""). This function call allows them to retrieve the full cached contents of cluster-scoped GlobalContextEntry objects, effectively granting read access to data that should remain restricted based on Role-Based Access Control RBAC permissions.
From a technical perspective, this flaw constitutes an improper privilege escalation and information disclosure vulnerability. The core issue lies in the lack of namespace scoping for global context retrieval operations. When a tenant creates a namespaced policy such as a NamespacedValidatingPolicy or any other namespaced mutating deleting generating or image-validating policy kind they can embed CEL expressions that query global contexts. Because the admission validation logic does not reject these calls, and because the library returns cached data regardless of the caller's RBAC permissions on specific namespaces, an attacker can enumerate sensitive configuration details stored in GlobalContextEntry resources across the entire cluster. This includes potentially secret keys internal configurations or other metadata from namespaces where the tenant has no legitimate access rights. The vulnerability exploits the trust model inherent in Kyverno policy execution assuming that namespace-scoped policies cannot affect or observe data outside their scope, which is demonstrably false due to this library registration oversight.
The operational impact of this vulnerability is severe for multi-tenant Kubernetes environments and organizations utilizing Kyverno for strict compliance enforcement. Attackers who gain the ability to create namespaced policies can perform unauthorized reconnaissance by extracting sensitive information from other namespaces or cluster-wide configurations. This data leakage could facilitate further attacks such as credential theft configuration manipulation or lateral movement within the cluster infrastructure. The absence of admission validation means that malicious actors do not need elevated privileges beyond policy creation rights in their own namespace, lowering the barrier for exploitation significantly. For security teams relying on Kyverno to enforce isolation boundaries between tenants this flaw undermines the fundamental principle of least privilege and compromises the integrity of multi-tenancy architectures.
This vulnerability aligns with CWE Category 284 Improper Access Control as it allows an actor to access resources they are not authorized to view due to a failure in enforcing namespace boundaries. It also maps to MITRE ATT&CK Technique T1078 Valid Accounts specifically within the context of lateral movement and discovery where valid but limited credentials are used to gather information about other parts of the system that should be inaccessible. The exploitation path involves creating a malicious policy object which is then executed by the Kyverno controller, leveraging the globalcontext library to exfiltrate data. Mitigation requires immediate upgrading to version 1.19.1 or later where this namespace confinement issue has been resolved ensuring that all CEL libraries including global context access are properly scoped to prevent cross-namespace data leakage. Until an upgrade is performed administrators should restrict RBAC permissions for policy creation in namespaces and monitor for unusual patterns of GlobalContextEntry access via audit logs if available.