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):

#!/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...