Summary
A tenant who can create a NamespacedValidatingPolicy in their own namespace can read and write arbitrary objects anywhere in the cluster using the Kyverno admission controller's ServiceAccount. The namespace boundary that the namespaced CEL environment enforces on resource.get() and resource.post() can be bypassed by placing .. segments in the resource argument. The resource argument is not validated before being passed to pkg/cel/libs/context.go, which splits it on / and passes the tail segments as subresources to client-go. Since client-go's rest.Request.AbsPath assembles the path using path.Join, which resolves .., the request sent on the wire reaches a different endpoint than the pinned namespace describes.
Impact
Every namespaced CEL policy type is affected, since the vpol, mpol, gpol, dpol, and ivpol compilers all register resource.Lib. Starting from a namespaced configmaps endpoint, an attacker can use .. segments to traverse back to /api/v1 or the root, reaching any Kubernetes API path with the controller's identity and RBAC. The generating and deleting policy variants run in background and cleanup controllers that may hold wider RBAC permissions. This vulnerability is in the same class as GHSA-79gf-7frw-68m9 and GHSA-cvq5-hhx3-f99p, but uses a different mechanism not addressed by those fixes.
Detection
Audit all namespaced Kyverno policy objects for resource.get() or resource.post() CEL expressions where the resource argument contains .. or / characters beyond a simple resource name. Review Kyverno admission controller logs for API calls traversing outside expected namespace boundaries. The background and cleanup controllers' audit logs should be examined for unexpected cross-namespace or cluster-scoped object access.
Mitigation
Upgrade Kyverno to version 1.19.2 or later, which validates the resource argument before it is passed to client-go to prevent path traversal. Until an upgrade can be applied, restrict who can create namespaced Kyverno policy objects (namespacedvalidatingpolicies.kyverno.io and related CRDs) to fully trusted users.
Related Security Guidance
References
- GHSA-4pqm-wqq6-h9q2 — GitHub Security Advisory