GHSA-cvq5-hhx3-f99p Kyverno: Cross-Namespace Read Bypasses RBAC Isolation (CVE-2026-22039 Incomplete Fix)
SummaryCVE-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:**Namespace admin creates a Kyverno Policy in their namespace (standard RBAC)Policy uses `context.configMap.namespace: "victim-ns"` to reference another namespaceKyverno's admission controller service account (has cluster-wide `view` role) fetches the ConfigMapPolicy 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.PoCFull reproduction (5 minutes on `kind`):**Exploit policy:****Trigger and exfiltrate:****Result:** Namespace admin successfully read secrets from `victim-ns` despite having NO RBAC access.Impact**Severity: HIGH (CVSS 7.7)****Who is affected:**Any Kubernetes cluster running Kyverno v1.17.0 (and earlier) with namespace-scoped Policy creation enabled (default)Multi-tenant clusters where ConfigMaps contain sensitive dataAzure Kubernetes Service (AKS) and other managed K8s using Kyverno**Attack prerequisites:**Namespace admin privileges (standard RBAC in multi-tenant clusters)Ability to create Kyverno Policy resources (default for namespace admins)No cluster-admin required**What can be exfiltrated:**Any ConfigMap from any namespaceCommon targets: database credentials, API keys, service configurations, application secrets stored in ConfigMaps**Why this matters:**Namespace isolation is a fundamental Kubernetes security boundaryNamespace admin is an expected, common RBAC level in production multi-tenant clustersViolates the principle of least privilege and breaks multi-tenancy guarantees**Suggested fix:**
Apply the same namespace validation from `apicall.Fetch()` to `configmap.NewConfigMapLoader()`:Pass `policyNamespace` to `NewConfigMapLoader()`After variable substitution on `namespace`, validate resolved namespace == `policyNamespace`Return error if validation failsAlso audit other context loaders (`globalReference`, `imageRegistry`, `variable`) for the same pattern.**Tested versions:**Kyverno: v1.17.0 (latest, includes CVE-2026-22039 fix)Helm chart: 3.7.0Kubernetes: v1.35.0 (kind)
CVSS v3.1 score: 7.7