CVE-2026-22039: The Namespaced Policy That Wasn't

A "namespaced" Kyverno Policy could ask the admission controller to make Kubernetes API requests on its behalf — and nobody checked the URL pointed at the policy's own namespace. The Kyverno ServiceAccount, holding wide cluster RBAC, became a confused deputy for anyone allowed to kubectl apply -n my-ns a Policy object.

The advisory in plain English

Kyverno's policy language lets you enrich admission decisions with data fetched from the Kubernetes API. You write a context.apiCall entry like:

context:
- name: cm
  apiCall:
    urlPath: "/api/v1/namespaces/{{ request.namespace }}/configmaps/limits"
    jmesPath: "data"

At admission time the Kyverno controller pod opens its kubeconfig, substitutes any variables in urlPath, and uses its own ServiceAccount token to perform a raw GET (or POST) against the kube-apiserver. The result lands in the policy context as {{ cm }}.

The flaw, before 1.16.3 / 1.15.3: when the Policy was a namespaced object (kyverno.io/v1, kind: Policy, scoped to one namespace) the controller still happily executed the call with its own — typically cluster-wide — credentials, against any URL the policy author chose. Nothing tied the resolved path to the policy's namespace.

That's textbook confused-deputy. The principal allowed to create a Policy in team-a is "namespace admin of team-a". The principal making the API call is "Kyverno admission controller", with RBAC tuned for whatever Kyverno needs to do in the worst case — typically get/list on a lot of things across the cluster, sometimes write on the policy CRDs themselves. NVD scored this 9.9 for a reason: in default installs you can read across namespaces, and if kyverno-admission-controller has write on clusterpolicies.kyverno.io (which lets it manage its own resources), a namespaced policy can mint a ClusterPolicy by POSTing to the right collection URL.

The flawed function

pkg/engine/apicall/apiCall.go, pre-fix Fetch:

func (a *apiCall) Fetch(ctx context.Context) ([]byte, error) {
    call, err := variables.SubstituteAllInType(a.logger, a.jsonCtx, a.entry.APICall)
    if err != nil {
        return nil, fmt.Errorf("failed to substitute variables in context entry %s %s: %v",
            a.entry.Name, a.entry.APICall.URLPath, err)
    }
    data, err := a.Execute(ctx, &call.APICall)
    ...
}

There is no other body between substitution and execution. The apiCall struct itself carried no notion of which policy was performing the call:

type apiCall struct {
    logger   logr.Logger
    jp       jmespath.Interface
    entry    kyvernov1.ContextEntry
    jsonCtx  enginecontext.Interface
    executor Executor
}

Execute hands the path to a thin K8s client:

func (a *executor) executeK8sAPICall(ctx context.Context, path string, method kyvernov1.Method, data []kyvernov1.RequestData) ([]byte, error) {
    ...
    jsonData, err := a.client.RawAbsPath(ctx, path, string(method), requestData)
    ...
}

RawAbsPath is the controller's own client. There is no impersonation, no User-Impersonate header, no narrowing wrapper. Whatever the controller can do, this call can do.

The connection between policy and execution lived in pkg/engine/factories/contextloaderfactory.go, whose pre-fix factory built loaders without even looking at the policy:

func DefaultContextLoaderFactory(cmResolver engineapi.ConfigmapResolver, opts ...ContextLoaderFactoryOptions) engineapi.ContextLoaderFactory {
    return func(_ kyvernov1.PolicyInterface, _ kyvernov1.Rule) engineapi.ContextLoader {
        cl := &contextLoader{
            logger:     logging.WithName("DefaultContextLoaderFactory"),
            cmResolver: cmResolver,
        }
        ...
    }
}

Both PolicyInterface parameters discarded with _. The information needed to enforce isolation was on the stack and thrown away.

Why the check was insufficient

There was no check. That's the whole story. The implicit assumption was that any path constructed by a policy author is trustworthy because policies are admin-grade objects. That assumption is fine for a ClusterPolicy (creating one requires cluster-scoped RBAC) but invalid for a namespaced Policy, where the trust boundary is one namespace.

Two design choices amplified it:

1. Free-form urlPath string with variable substitution. The schema is just URLPath string with a docstring pointing at kubectl get --raw syntax. There is no parser. Substitution happens on the raw string, so urlPath: "/api/v1/namespaces/{{ x }}/secrets" works exactly as written.
2. Single ServiceAccount with broad RBAC. Kyverno's admission controller historically asks for a generous ClusterRole to keep policy authoring frictionless. The "what could this token do" set is essentially "anything any Kyverno user ever wanted to read."

Together they form an ambient authority gun aimed at a feature anyone with namespace Policy-create can pull.

What the fix changed

Two PRs, one for 1.16 and one for 1.15 (e0ba4de4f and eba60fa85), touch the same four files identically. The shape:

1. Plumb the policy namespace down to the call site. DefaultContextLoaderFactory now reads the policy:

return func(policy kyvernov1.PolicyInterface, _ kyvernov1.Rule) engineapi.ContextLoader {
    policyNamespace := ""
    if policy != nil && policy.IsNamespaced() {
        policyNamespace = policy.GetNamespace()
    }
    cl := &contextLoader{
        logger:          logging.WithName("DefaultContextLoaderFactory"),
        cmResolver:      cmResolver,
        policyNamespace: policyNamespace,
    }
    ...
}

policy.IsNamespaced() already existed — Policy returns true, ClusterPolicy returns false. The empty string sentinel is "this is a ClusterPolicy, don't apply the check." That's important: ClusterPolicies still need to make cluster-scoped calls.

2. Threaded through to apiCall. apiLoader grows a policyNamespace field, and apicall.New gains a final string parameter. Test fixtures all pass "" to preserve old behavior for cluster-scoped suites.

3. The actual enforcement. A new regex and seven lines inside Fetch:

var namespacePathRegex = regexp.MustCompile(`^/api(s)?/.*?/namespaces/([^/]+)/?.*$`)

...

if a.policyNamespace != "" {
    cleanPath := path.Clean(call.APICall.URLPath)
    if matches := namespacePathRegex.FindStringSubmatch(cleanPath); len(matches) > 2 {
        ns := matches[2]
        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 {
        return nil, fmt.Errorf("path %s does not contain a namespace segment, which is required for namespaced policies", cleanPath)
    }
}

A few details worth lingering on:

• The check runs after variables.SubstituteAllInType. That's correct: variable-driven URL paths are the more interesting attack surface (the advisory calls this out by name), and the check must see the post-substitution path.
• path.Clean collapses .. and double slashes before the regex sees the string, so an attempt to obscure the namespace segment with traversal doesn't shift it past the matcher.
• The regex is anchored with ^/api(s)?/, then a lazy .*? up to the first /namespaces/, then ([^/]+) for the namespace name. [^/]+ prevents smuggling extra path segments into the capture group.
• Cluster-scoped URLs (/api/v1/nodes, /apis/kyverno.io/v1/clusterpolicies, /api/v1/namespaces itself) don't contain /namespaces/<name>/, so they fall into the "does not contain a namespace segment" branch and are rejected for namespaced policies. That's how the "namespaced Policy can create a ClusterPolicy" path is closed — the collection URL has no namespace segment.
• ClusterPolicies (a.policyNamespace == "") skip the whole block. Their author already had cluster-scoped Policy create rights; nothing to escalate.

The regression tests (Test_CrossNamespaceAccess, Test_CrossNamespaceAccess_WithVariableSubstitution) lock in the four interesting transitions: cross-ns blocked, same-ns allowed, cluster-scoped blocked from namespaced, ClusterPolicy unaffected.

The lesson

This is a confused-deputy bug in the most literal sense: feature design conflated the principal authoring the policy with the principal executing the API call. The fix is correct and minimal, but it's the kind of thing that should have been wired in on day one of the feature. A few principles worth carrying forward:

1. Trust boundaries follow the object's RBAC scope, not the controller's. Anything a namespaced object can configure to happen must be re-checked against the namespace, even if the controller is the one doing it.
2. Ambient authority is a hazard. Whenever a controller acts with its own token on behalf of user-supplied configuration, the gap between "what the user could do" and "what the controller can do" is your blast radius. Either narrow the controller (split ServiceAccounts), impersonate the requester, or constrain inputs — but don't leave the gap unmanaged.
3. Variable substitution in security-sensitive strings is a parser problem. If urlPath had been a typed structure (verb + group + version + namespace + name) instead of a free-form string, this regex wouldn't exist because the namespace would be a field. Stringly-typed inputs invite stringly-typed checks invite regex retrofits.
4. The right place to enforce isolation is at the construction site, with the right parameter plumbed in. The diff is mostly plumbing. The actual policy ("namespaced policies must only touch their own namespace") is one if block. The bulk of the work was admitting the call site had no idea who was calling.

For Kyverno operators on affected versions: 1.16.3 and 1.15.3 are the fixed releases. Until you're patched, the de facto mitigation is to audit who has create on policies.kyverno.io in your cluster, since on pre-fix versions that permission is effectively "ambient cluster read, and possibly write to whatever Kyverno's ServiceAccount can reach."

References

• https://github.com/kyverno/kyverno/security/advisories/GHSA-8p9x-46gm-qfx2
• https://github.com/kyverno/kyverno/commit/e0ba4de4f1e0ca325066d5095db51aec45b1407b
• https://github.com/kyverno/kyverno/commit/eba60fa856c781bcb9c3be066061a3df03ae4e3e