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

CVE-2026-100706 is a critical privilege escalation vulnerability in Kyverno, a Kubernetes-native policy engine, caused by improper validation of URL-encoded path segments in Policy apiCall urlPath. Versions of Kyverno before 1.19.1 are affected. The vulnerability allows authenticated namespace tenants to bypass the per-namespace clamp and create objects in arbitrary namespaces — or cluster-wide — as the admission-controller ServiceAccount, ultimately enabling escalation to cluster admin. It was disclosed on September 26, 2026, with a patch available in version 1.19.1. It carries a CVSS v3.1 score of 9.9 (Critical) and a CVSS v4.0 score of 9.4 (Critical) (GitHub Advisory, GHSA-j68q-wq49-88gg).

The root cause is a "decode-after-clamp" logic flaw (CWE-441: Confused Deputy; CWE-22: Path Traversal) in kyverno/pkg/engine/apicall/apiCall.go. The namespace clamp validates path.Clean(call.APICall.URLPath) — which does not URL-decode — and extracts the namespace from the cleaned string, but then passes the raw (un-decoded) urlPath to Execute() and ultimately to RawAbsPath(). The dynamic client forwards the raw path to client-go, which URL-decodes %2e%2e to .. and resolves the traversal, so the API server receives a path pointing to a different namespace or cluster-scoped collection than the clamp validated. An attacker crafts a urlPath such as /apis/kyverno.io/v2/namespaces/tenant-ns/%2e%2e/kyverno/policyexceptions — the clamp sees tenant-ns, but the API server receives a request targeting the kyverno namespace. Two concrete attack paths are documented: (A) creating a MutatingWebhookConfiguration cluster-wide to intercept and rewrite admitted objects, and (B) injecting a PolicyException into the kyverno namespace to disable enforcing policies (GitHub Advisory).

Successful exploitation allows any authenticated namespace tenant with create on policies.kyverno.io in their own namespace to escalate privileges to cluster administrator. Via Attack Path A, the attacker registers a MutatingWebhookConfiguration cluster-wide, enabling interception and modification of any admitted object across the entire cluster. Via Attack Path B, the attacker disables enforcing Kyverno policies for their namespace by injecting a PolicyException, allowing privileged workloads (e.g., privileged pods) to run — from which a full node escape and cluster-admin credential theft is trivial. The impact spans confidentiality, integrity, and availability of the entire Kubernetes cluster, not just the attacker's namespace (GitHub Advisory, GHSA-j68q-wq49-88gg).

As of the disclosure date (September 26, 2026), there is no public proof-of-concept exploit code and no evidence of in-the-wild exploitation. The EPSS score is 0.0, and the vulnerability is not listed in the CISA KEV catalog. However, the advisory includes detailed reproduction steps and two demonstrated attack paths verified on a live kind v1.31.0 cluster running Kyverno v1.18.1, lowering the bar for exploitation by a knowledgeable attacker. The vulnerability requires only low privileges (namespace tenant with create on Kyverno policies) and no user interaction (GitHub Advisory, GHSA-j68q-wq49-88gg).

1. Reconnaissance: Identify a Kubernetes cluster running Kyverno before version 1.19.1. Confirm the attacker has a namespace tenant identity with create/get on policies.kyverno.io in their namespace and the built-in edit ClusterRole bound to their ServiceAccount.

2. Determine attack path: Check whether PolicyException is enabled (--enablePolicyException=true) and confined to the kyverno namespace (--exceptionNamespace=kyverno). If so, Attack Path B (policy bypass) is available in addition to Attack Path A (webhook injection).

3. Craft malicious Policy (Attack Path A — MutatingWebhookConfiguration): As the tenant, create a namespaced kyverno.io/v1.Policy with a method: POST apiCall whose urlPath uses percent-encoded traversal to reach the cluster-scoped MutatingWebhookConfiguration collection, e.g., /apis/admissionregistration.k8s.io/v1/namespaces/tenant-ns/%2e%2e/%2e%2e/mutatingwebhookconfigurations. The clamp validates tenant-ns; client-go resolves the path to the cluster-scoped collection.

4. Trigger the apiCall: Create any resource in the tenant namespace that matches the policy's match block (e.g., a ConfigMap). Kyverno's admission controller executes the apiCall as its own ServiceAccount, POSTing the attacker-supplied body to the resolved cluster-scoped path.

5. Register malicious webhook (Attack Path A): The created MutatingWebhookConfiguration intercepts admission requests cluster-wide, allowing the attacker to rewrite objects, inject environment variables, or escalate further.

6. Craft malicious Policy (Attack Path B — PolicyException injection): Create a namespaced Policy whose apiCall POSTs a PolicyException to /apis/kyverno.io/v2/namespaces/tenant-ns/%2e%2e/kyverno/policyexceptions, targeting the kyverno namespace. The exception disables an enforcing policy (e.g., disallow-privileged-containers) for the tenant's namespace.

7. Run privileged workload: After the PolicyException is created in the kyverno namespace by the admission-controller SA, deploy a privileged pod in the tenant namespace. The previously enforcing policy now admits it.

8. Escalate to cluster admin: From the privileged pod, perform a node escape (e.g., mount the host filesystem, access kubelet credentials, or steal the cluster-admin kubeconfig) to achieve full cluster compromise (GitHub Advisory).

• Kubernetes Audit Logs: POST requests to the Kubernetes API server originating from the Kyverno admission-controller ServiceAccount (system:serviceaccount:kyverno:kyverno-admission-controller) targeting namespaces or resources outside the Kyverno namespace or cluster-scoped collections (e.g., mutatingwebhookconfigurations, policyexceptions in the kyverno namespace) that were not initiated by a cluster administrator.
• Kubernetes Audit Logs: Creation of MutatingWebhookConfiguration objects attributed to the Kyverno admission-controller ServiceAccount without a corresponding legitimate Kyverno operator action.
• Kubernetes Audit Logs: Creation of PolicyException objects in the kyverno namespace attributed to the Kyverno admission-controller ServiceAccount, especially those exempting tenant namespaces from enforcing policies.
• Kyverno Policy Objects: Presence of namespaced kyverno.io/v1.Policy objects in tenant namespaces containing apiCall entries with urlPath values containing percent-encoded sequences such as %2e%2e, %2f, ..%2f, or .%2e.
• Workload Behavior: Privileged pods running in tenant namespaces that should have been blocked by enforcing Kyverno policies (e.g., disallow-privileged-containers).
• Network: Unexpected outbound connections from privileged pods to external IPs, or unusual access to the host network/filesystem from within a pod (GitHub Advisory).

Upgrade Kyverno to version 1.19.1 or later, which properly URL-decodes path segments before applying the namespace clamp check. The fix requires either URL-decoding and path.Clean-ing the urlPath before namespace extraction, or constructing requests from a parsed (group, version, namespace, resource, name) tuple and rejecting any namespace that differs from the policy's namespace. If an immediate upgrade is not possible, restrict RBAC permissions so that untrusted namespace tenants cannot create policies.kyverno.io resources, and use network policies to limit access to the Kyverno admission-controller service. Additionally, monitor Kubernetes audit logs for anomalous API calls originating from the Kyverno ServiceAccount (GitHub Advisory, VulnCheck Advisory).

The vulnerability was credited to researcher Artem Cherezov (@cherez0ff), who discovered it during an audit of Kyverno v1.18.1. The advisory notes similarity to a prior critical Kyverno vulnerability (GHSA-8p9x-46gm-qfx2 / CVE-2026-22039), suggesting a pattern of namespace isolation bypass issues in the project. Coverage appeared on The Hacker Wire shortly after disclosure, and the vulnerability was discussed on Mastodon. No major vendor statements beyond the Kyverno project's own advisory have been observed (GitHub Advisory).