CVE-2026-22039: 
Wolfi vulnerability analysis and mitigation

CVE-2026-22039 is a critical authorization boundary bypass vulnerability in Kyverno, a policy engine for cloud-native Kubernetes environments, titled "Kyverno Cross-Namespace Privilege Escalation via Policy apiCall." It affects all versions prior to 1.15.3 and versions 1.16.0 through 1.16.2, and was disclosed on January 27, 2026. Any authenticated user with permission to create a namespaced Policy can exploit this flaw to cause Kyverno's admission controller to perform Kubernetes API requests beyond the policy's namespace scope. It carries a CVSS v3.1 base score of 9.9 (Critical) (GitHub Advisory, Kyverno Security Advisory).

The root cause is improper privilege management (CWE-269) combined with Server-Side Request Forgery (CWE-918). In pkg/engine/apicall/apiCall.go, the Fetch method calls variables.SubstituteAllInType to perform variable substitution on the entire APICall object — including the URLPath field — without validating that the resulting path is scoped to the policy's namespace. The substituted path is then passed directly to RawAbsPath in executor.go, which executes a raw HTTP request to the Kubernetes API server using Kyverno's admission controller ServiceAccount (which typically holds broad cluster-wide RBAC permissions). An attacker can craft a namespaced Policy with a context apiCall entry whose urlPath uses variable substitution to resolve to an arbitrary API path — such as /api/v1/namespaces/kube-system/secrets/top-secret — bypassing namespace isolation entirely (GitHub Advisory, Kyverno Security Advisory).

Successful exploitation allows an attacker with only namespace-scoped Policy creation rights to read sensitive resources across any namespace (e.g., ConfigMaps and Secrets in kube-system) and perform cluster-scoped or cross-namespace writes (e.g., creating ClusterPolicies), effectively breaking Kubernetes namespace isolation. This enables privilege escalation from a low-privileged namespace user to a position with cluster-admin-equivalent read/write capabilities via Kyverno's admission controller identity. The potential for lateral movement across the cluster and exfiltration of sensitive credentials or configuration data is high (GitHub Advisory, Kyverno Security Advisory).

A detailed proof-of-concept (PoC) is publicly documented in the official security advisory, demonstrating step-by-step data exfiltration from kube-system by a user restricted to the default namespace. No evidence of in-the-wild exploitation or threat actor attribution has been reported at this time. The EPSS score is approximately 0.037% (0.000370), indicating a currently low probability of active exploitation. The vulnerability is not listed in the CISA KEV catalog (GitHub Advisory, Kyverno Security Advisory).

1. Identify a vulnerable target: Confirm the Kubernetes cluster is running Kyverno versions prior to 1.15.3 or between 1.16.0 and 1.16.2 using kubectl get pods -n kyverno and checking the image tag.
2. Obtain namespace-scoped Policy creation rights: Acquire or already possess RBAC permissions to create policies.kyverno.io resources in a target namespace (e.g., default).
3. Identify a sensitive target resource: Determine a high-value resource in another namespace, such as a ConfigMap or Secret in kube-system (e.g., /api/v1/namespaces/kube-system/configmaps/target-cm).
4. Craft a malicious namespaced Policy: Create a Kyverno Policy in the attacker-controlled namespace with an apiCall context entry whose urlPath references the cross-namespace resource path, optionally using context variable substitution to obfuscate the target path (e.g., urlPath: /api/v1/namespaces/{{ targetNs }}/configmaps/target-cm).
5. Apply the policy: Submit the malicious Policy using kubectl apply -f malicious-policy.yaml --as=system:serviceaccount:default:policy-admin.
6. Trigger policy evaluation: Cause an admission event in the namespace (e.g., create a Pod) to trigger Kyverno's engine to evaluate the policy and execute the apiCall using the admission controller's ServiceAccount.
7. Exfiltrate data: Retrieve the fetched data from the policy evaluation result or a ConfigMap written by the policy, containing the sensitive cross-namespace resource content (GitHub Advisory, Kyverno Security Advisory).

• Kubernetes Audit Logs: API server audit logs showing the Kyverno admission controller ServiceAccount (system:serviceaccount:kyverno:kyverno-admission-controller) performing GET or POST requests to namespaces or resources outside the Kyverno namespace, particularly to kube-system or other sensitive namespaces.
• Kyverno Engine Logs: Unexpected apiCall context entries resolving to cross-namespace paths in Kyverno controller logs; errors such as path refers to namespace X, which is different from the policy namespace Y on patched versions may indicate attempted exploitation.
• Policy Artifacts: Namespaced Policy resources containing context.apiCall.urlPath values referencing namespaces other than the policy's own namespace, or using variable substitution patterns (e.g., {{ someVar }}) in the urlPath field.
• Resource Access Anomalies: Unexpected reads of Secrets or ConfigMaps in privileged namespaces (e.g., kube-system) attributed to the Kyverno ServiceAccount in audit logs without a corresponding ClusterPolicy justification.
• New ClusterPolicy Resources: Unexpected ClusterPolicy objects created without administrator action, potentially authored via a cross-namespace write exploit (GitHub Advisory).

Upgrade Kyverno to version 1.15.3 (for v1.15.x deployments) or 1.16.3 (for v1.16.x deployments), which enforce namespace isolation by validating that the resolved urlPath in namespaced Policy apiCall entries contains a namespace segment matching the policy's own namespace, and rejecting requests targeting cluster-scoped resources or other namespaces. As an interim workaround, restrict RBAC permissions to limit which users can create namespaced Policy resources, and audit existing namespaced Policies for suspicious apiCall entries with variable substitution in urlPath. The fix was applied in commits e0ba4de (v1.16.x) and eba60fa (v1.15.x) (GitHub Advisory, Patch Commit v1.16.x, Patch Commit v1.15.x).

The Kubewarden project published a blog post clarifying that it is not affected by CVE-2026-22039, noting architectural differences that prevent the same class of vulnerability (Kubewarden Blog). The vulnerability received coverage from security news outlets including Security Online, which highlighted the cluster-admin-equivalent impact under the headline "Cluster Admin for All" (Security Online). Discussion on Reddit's r/kubernetes community explored how the admission controller architecture contributed to the vulnerability's severity. The Hacker News weekly recap also referenced the flaw in the context of notable Kubernetes security events.