Kyverno's namespace clamp failed on a percent-encoded path
Kyverno policies can call Kubernetes APIs on behalf of a namespace tenant. That makes the admission controller a useful bridge: a policy can read related objects without granting the tenant direct cluster-wide access. CVE-2026-124440 breaks that bridge when a malformed percent-escape in urlPath lets the caller escape the namespace clamp.
The GitHub-reviewed advisory and CVE record describe an authorization bypass in Kyverno 1.19.1 before 1.19.2. A namespace tenant can issue cross-namespace and cluster-scoped API requests by appending malformed percent-escapes to the path. The request is executed with the Kyverno admission controller's ServiceAccount, not with the requesting user's identity.
That distinction is the security problem. The controller is expected to constrain a policy's API call to the namespace where the policy applies. When the clamp is bypassed, the controller's own authority becomes the attacker's authority. The result is not a path traversal on a static file server. It is a privileged API client making a request the policy author was not supposed to reach.
How a path becomes an authorization result
The policy engine constructs an API request from a policy field such as urlPath. It must decide which namespace is the intended boundary, join the path safely, and send the request through the Kubernetes client. Path normalization is part of that decision. A percent-encoded segment can look confined to the tenant namespace to one parser and resolve to a different resource to the API server.
Kyverno's service account can often list namespaces, read secrets metadata, inspect workloads, or call other APIs required by policy logic. The exact blast radius depends on the controller's RBAC. The important point is that a tenant who can create or modify a namespaced policy may obtain requests the tenant could not make directly.
This is a confused-deputy flaw with a familiar shape. The controller has legitimate cluster authority. The tenant controls a policy input. The boundary between them is a path transformation. If the transformation is not applied consistently before authorization, the controller can be induced to act outside its intended context.
Which clusters need attention
Focus on Kyverno 1.19.1 deployments where users outside the cluster administration group can create, update, or template namespaced policies. A cluster where only a small platform team can author policies still needs the upgrade, but the practical risk is lower. A multi-tenant cluster where application teams can define policies deserves immediate validation.
Review the Kyverno service account's RBAC before and after the upgrade. A broad cluster-admin binding can turn a narrow path bug into a much larger disclosure. If the controller needs only specific resources, reduce its permissions and separate policy execution identities where the design permits. Policy authors should not be able to choose arbitrary service accounts or arbitrary external endpoints.
Check templates that derive urlPath from an AdmissionReview object, a ConfigMap, or another tenant-controlled field. These are the paths where a benign-looking template can become an injection point. Also inspect policies that use the legacy apiCall executor rather than newer CEL HTTP functions, because the implementation paths differ and the advisory applies to the legacy request builder.
Detection and verification
Search Kubernetes audit logs for API requests made by the Kyverno service account that contain percent escapes in resource paths or target a namespace outside the source policy's namespace. Correlate the request with policy creation and update events. A single anomalous request may be hidden among legitimate controller activity, so compare the source namespace, target resource, and policy version.
Do not test the vulnerability by issuing arbitrary cluster-scoped reads in production. Use a staging cluster with a dedicated service account and a harmless resource. The validation should show that a namespaced policy cannot reach another namespace through encoded path variants after the upgrade. Then verify that legitimate policy API calls still work.
Upgrade to Kyverno 1.19.2 or later. If the upgrade cannot land immediately, restrict policy creation to cluster administrators and remove unused apiCall policies. NetworkPolicy can limit where the controller sends requests, but it does not repair the namespace authorization decision. Treat the path bug as an RBAC problem first.
The durable fix is to compute a canonical target before applying the namespace clamp and to use the same canonical value for authorization and request construction. A percent escape is only the current example. Any disagreement between the policy parser and the Kubernetes API path resolver can produce the same class of failure.
Top comments (0)