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

CVE-2026-100707 is a namespace isolation bypass vulnerability in Kyverno, a Kubernetes-native policy engine, affecting all versions before 1.19.1. The flaw resides in the apiCall context entry of namespaced Policy resources and allows a low-privilege tenant to read Kubernetes resources from other namespaces by exploiting inconsistent path interpretation between the validation and execution stages. It was published on September 26, 2026, with a patch available in version 1.19.1. The vulnerability carries a CVSS v3.1 score of 7.7 (High) and a CVSS v4.0 score of 8.3 (High) (GitHub Advisory, Github Advisory).

The root cause is a path traversal issue (CWE-22) arising from inconsistent handling of percent-encoded dot-segments (%2e%2e) between the namespace isolation check and the actual API request execution. In pkg/engine/apicall/apiCall.go, the check uses path.Clean() — a purely lexical normalizer that does not percent-decode — so a crafted path like /api/v1/namespaces/attacker-ns/%2e%2e/victim-ns/configmaps/victim-config passes validation because the regex captures attacker-ns as the namespace. However, in pkg/engine/apicall/executor.go, the raw URLPath is passed to client-go's rest.Request.RequestURI(), which calls url.Parse() and percent-decodes %2e%2e into .., resolving the dot-segments and directing the request to the victim namespace. The request is executed using the Kyverno admission controller's ServiceAccount credentials, not the requesting user's identity, enabling a confused-deputy attack (GitHub Advisory).

A low-privilege tenant who can only create namespaced Policies in their own namespace — with no direct access to other namespaces — can read Kubernetes resources across all namespaces using the Kyverno admission controller's ServiceAccount permissions. In a default installation, this exposes ConfigMaps and Namespaces cluster-wide; if the controller ServiceAccount is granted Secret read access (a documented configuration for image-pull or TLS credential policies), the attack can yield cross-namespace Secret theft, potentially exposing ServiceAccount tokens, kubeconfig secrets, and credentials that could facilitate cluster takeover. There is no integrity or availability impact, but the confidentiality breach is severe in multi-tenant clusters where namespace boundaries are treated as isolation guarantees (GitHub Advisory).

There is no public proof-of-concept exploit code and no evidence of in-the-wild exploitation at the time of disclosure (Feedly). The vulnerability requires only low privileges — specifically, the ability to create a namespaced Policy in one namespace — making it accessible to any namespace-level tenant in a multi-tenant cluster. The EPSS score is 0.0, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. The attack is network-accessible, requires no user interaction, and has low complexity, making it straightforward to exploit once the precondition is met (GitHub Advisory).

1. Identify target: Confirm the cluster is running Kyverno before version 1.19.1 and that the attacker has permission to create namespaced Policy resources in their own namespace (e.g., attacker-ns).
2. Identify victim resources: Determine the target namespace (e.g., victim-ns) and the resource to exfiltrate (e.g., a ConfigMap named victim-config).
3. Craft malicious Policy: Create a namespaced Kyverno Policy in attacker-ns with an apiCall context entry using a percent-encoded path traversal payload in urlPath:

   context:
   - name: stolen
     apiCall:
       method: GET
       urlPath: "/api/v1/namespaces/attacker-ns/%2e%2e/victim-ns/configmaps/victim-config"

4. Bypass namespace check: The validation logic in apiCall.go uses path.Clean() (which does not percent-decode), so the regex captures attacker-ns as the namespace and the check passes.
5. Trigger policy execution: Create any ConfigMap in attacker-ns to trigger the admission webhook and cause Kyverno to evaluate the policy.
6. Exfiltrate data: The executor passes the raw urlPath to client-go, which percent-decodes %2e%2e to .. and resolves the path to victim-ns. The request is made with the Kyverno admission controller's ServiceAccount, and the response (containing the victim's resource data) is surfaced in the policy's validation message or denial output, leaking the cross-namespace data to the attacker (GitHub Advisory).

• Kubernetes Audit Logs: API server audit logs showing GET requests to cross-namespace resource paths (e.g., /api/v1/namespaces/<victim-ns>/configmaps/) originating from the Kyverno admission controller's ServiceAccount (system:serviceaccount:kyverno:kyverno-admission-controller or similar), where the requesting user is a low-privilege tenant ServiceAccount in a different namespace.
• Kyverno Policy Resources: Presence of namespaced Policy objects containing apiCall context entries with urlPath values including percent-encoded sequences such as %2e%2e, %2F, or other encoded path traversal characters.
• Admission Webhook Activity: Unusual or repeated admission webhook invocations (e.g., ConfigMap creates in a tenant namespace) that correlate with cross-namespace API calls in audit logs.
• Policy Validation Messages: Kyverno denial or validation messages in event logs that contain data from resources in namespaces other than the policy's own namespace, indicating successful data exfiltration via the policy message template (GitHub Advisory).

Upgrade Kyverno to version 1.19.1 or later, which contains the fix for this vulnerability (GitHub Advisory). As interim mitigations, restrict the ability to create namespaced Policy resources to trusted users only via RBAC, and audit existing Policy resources for apiCall context entries with suspicious urlPath values containing percent-encoded characters. Additionally, review and minimize the permissions granted to the Kyverno admission controller's ServiceAccount to reduce the blast radius if exploitation occurs — in particular, avoid granting Secret read access unless strictly necessary (Feedly).