Summary
Kyverno before 1.19.1 contains a namespace isolation bypass in the apiCall context entry of namespaced Policy resources. A low-privilege tenant may exploit inconsistent URL path interpretation to read resources from other namespaces through the Kyverno admission controller's ServiceAccount credentials.
Affected context
The issue can arise in Kyverno deployments that use namespaced Policy resources with apiCall context entries. It depends on namespace restrictions being validated using a different path interpretation from the one later used during request execution, allowing specially encoded path components to evade isolation checks.
Exploit preconditions
- Attack surface: Kyverno Policy
apiCallhandling in the admission controller - Required access: Low-privilege tenant access sufficient to create or influence an applicable namespaced Policy
- Trigger point: Evaluation of the Policy's
apiCallcontext entry during admission processing - Authorization context: The Kyverno admission controller's ServiceAccount credentials are used for the downstream resource request
- Why exploitation is possible: Validation and execution interpret URL paths inconsistently, permitting namespace checks to be bypassed
Why this happens
The underlying bug is an inconsistent interpretation of path syntax between authorization validation and request execution. Path components that represent traversal or normalization semantics may be treated as ordinary text during namespace checks but interpreted structurally when the request is performed.
This behavior maps to CWE-22: Improper Limitation of a Pathname to a Restricted Directory, applied here to namespace-scoped resource paths. The insecure pattern is relying on non-canonical input during authorization decisions without ensuring that validation and execution use the same normalized representation.
Potential impact
- A tenant could read resources from namespaces outside its authorized scope
- Sensitive configuration, metadata, or workload information may be disclosed
- Exposed data could support reconnaissance or follow-on attacks
- The effective permissions of the Kyverno ServiceAccount could broaden the disclosure impact
- Cross-tenant isolation guarantees may be weakened
General mitigation guidance
Mitigation generally focuses on making authorization and request execution operate on one canonical, consistently interpreted path representation.
Common defensive patterns include:
- Normalize and validate path components before applying namespace authorization decisions
- Reject ambiguous, encoded, or traversal-style path representations where they are not required
- Use structured Kubernetes resource identifiers instead of concatenated URL paths
- Apply explicit allowlists for permitted resource types, namespaces, and operations
- Reduce the Kyverno ServiceAccount permissions to the minimum required scope
- Treat tenant-controlled Policy content as untrusted and restrict which users may define
apiCallentries - Add regression tests covering canonicalization, encoding, and namespace-boundary cases
How teams detect issues like this
Detection can combine code analysis, policy review, and runtime monitoring:
- Use static analysis to identify authorization checks performed before path canonicalization or normalization
- Review code for differences between URL validation libraries and the client used to execute requests
- Flag string-based construction of Kubernetes API paths from tenant-controlled Policy fields
- Enforce admission policies that restrict
apiCallusage in namespaced Policies - Audit Kyverno ServiceAccount permissions and monitor cross-namespace API requests
- Add automated tests and security review checks for encoded separators, dot-segments, and equivalent path forms
