GHSA-cvq5-hhx3-f99p

### Summary CVE-2026-22039 fixed cross-namespace privilege escalation in Kyverno's `apiCall` context by validating the `URLPath` field. However, the **ConfigMap context loader has the identical vulnerability** — the `configMap.namespace` field accepts any namespace with zero validation, allowing a namespace admin to read ConfigMaps from any namespace using Kyverno's privileged service account. This is a complete RBAC bypass in multi-tenant Kubernetes clusters. ### Details **Root cause:** The CVE-2026-22039 fix in `pkg/engine/apicall/apiCall.go` (lines 73-83) validates that `URLPath` references only the policy's own namespace using regex. However, the ConfigMap context loader at `pkg/engine/context/loaders/configmap.go` performs **no namespace validation** on the `namespace` field. **Code path comparison:** | | CVE-2026-22039 (fixed) | This vulnerability (unfixed) | |--|---|---| | **Location** | `apiCall.URLPath` field | `configMap.namespace` field | | **Code path** | `apicall.Fetch()` → namespace regex validation | `configmap.NewConfigMapLoader()` → no validation | | **Root cause** | Variable substitution + missing validation | Same pattern, still unpatched | **Exploit mechanism:** 1. Namespace admin creates a Kyverno Policy in their namespace (standard RBAC) 2. Policy uses `context.configMap.namespace: "victim-ns"` to reference another namespace 3. Kyverno's admission controller service account (has cluster-wide `view` role) fetches the ConfigMap 4. Policy mutates a trigger ConfigMap to exfiltrate the stolen data via annotations **Affected code:** `pkg/engine/context/loaders/configmap.go` - `NewConfigMapLoader()` does not validate resolved namespace against policy namespace. ### PoC Full reproduction (5 minutes on `kind`): ```bash #!/bin/bash # Setup: kind cluster + Kyverno v1.17.0 kind create cluster --name kyverno-poc --wait 60s helm repo add kyverno https://kyverno.github.io/kyverno/ helm install kyverno kyverno/kyverno --namespace kyverno --create-nam