Summary
Kyverno does not validate path segments in the resource argument to CEL resource.get() and resource.post(), allowing a namespaced policy to traverse beyond its namespace. A tenant who can create a NamespacedValidatingPolicy may use this behavior to read or write cluster objects accessible to the admission controller's ServiceAccount, potentially compromising the cluster.
Kyverno does not validate path segments in the resource argument to CEL resource.get() and resource.post(), allowing a namespaced policy to traverse beyond its namespace. A tenant who can create a NamespacedValidatingPolicy may use this behavior to read or write cluster objects accessible to the admission controller's ServiceAccount, potentially compromising the cluster.
Affected context
The issue affects Kyverno versions from 1.16.0 up to, but not including, 1.19.2, where namespaced CEL policies use resource.get() or resource.post(). Risk depends on whether a tenant can create a NamespacedValidatingPolicy and whether the admission controller's ServiceAccount has permissions over objects beyond that tenant's namespace.
The issue affects Kyverno versions from 1.16.0 up to, but not including, 1.19.2, where namespaced CEL policies use resource.get() or resource.post(). Risk depends on whether a tenant can create a NamespacedValidatingPolicy and whether the admission controller's ServiceAccount has permissions over objects beyond that tenant's namespace.
Exploit preconditions
- Attack surface: CEL resource access through Kyverno's admission controller
- Required access: Permission to create a NamespacedValidatingPolicy
- Trigger point: Evaluation of a policy that calls
resource.get()orresource.post()with a resource argument containing path traversal segments - Why exploitation is possible: Path segments are not adequately validated, allowing a namespaced policy to escape its namespace and act with the admission controller's ServiceAccount permissions
- Attack surface: CEL resource access through Kyverno's admission controller
- Required access: Permission to create a NamespacedValidatingPolicy
- Trigger point: Evaluation of a policy that calls
resource.get()orresource.post()with a resource argument containing path traversal segments - Why exploitation is possible: Path segments are not adequately validated, allowing a namespaced policy to escape its namespace and act with the admission controller's ServiceAccount permissions
Why this happens
The resource argument is used without adequately validating its path segments. Traversal segments such as .. can cause a resource operation intended to be namespaced to resolve outside that namespace. This is a path traversal flaw mapped to CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal').
The resource argument is used without adequately validating its path segments. Traversal segments such as .. can cause a resource operation intended to be namespaced to resolve outside that namespace. This is a path traversal flaw mapped to CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal').
Potential impact
- A policy author may be able to read cluster objects outside their namespace.
- A policy author may be able to modify cluster objects the admission controller's ServiceAccount can access.
- Unauthorized writes could disrupt workloads or weaken cluster security controls.
- Broad ServiceAccount permissions could allow escalation to cluster takeover.
- A policy author may be able to read cluster objects outside their namespace.
- A policy author may be able to modify cluster objects the admission controller's ServiceAccount can access.
- Unauthorized writes could disrupt workloads or weaken cluster security controls.
- Broad ServiceAccount permissions could allow escalation to cluster takeover.
General mitigation guidance
Defensive approaches focus on enforcing namespace boundaries at the resource access layer, rather than relying on policy authors to provide safe paths.
- Validate and canonicalize resource identifiers, rejecting traversal segments and out-of-scope paths.
- Apply namespace and authorization checks to every resource operation.
- Prefer APIs that derive scope from trusted policy context instead of caller-controlled paths.
- Restrict the admission controller's ServiceAccount to the minimum permissions required.
- Limit who can create namespaced policies and apply policy review controls.
Defensive approaches focus on enforcing namespace boundaries at the resource access layer, rather than relying on policy authors to provide safe paths.
- Validate and canonicalize resource identifiers, rejecting traversal segments and out-of-scope paths.
- Apply namespace and authorization checks to every resource operation.
- Prefer APIs that derive scope from trusted policy context instead of caller-controlled paths.
- Restrict the admission controller's ServiceAccount to the minimum permissions required.
- Limit who can create namespaced policies and apply policy review controls.
How teams detect issues like this
- Review resource access code for missing canonicalization, traversal checks, or authorization checks after path resolution.
- Use static analysis and code review rules to flag path components such as
..in resource identifiers. - Audit namespaced policies for calls to
resource.get()andresource.post()and assess whether their arguments can escape the namespace. - Monitor admission controller activity for unexpected reads or writes to resources outside the policy's namespace.
- Enforce policy validation and least-privilege authorization checks in development and deployment workflows.
- Review resource access code for missing canonicalization, traversal checks, or authorization checks after path resolution.
- Use static analysis and code review rules to flag path components such as
..in resource identifiers. - Audit namespaced policies for calls to
resource.get()andresource.post()and assess whether their arguments can escape the namespace. - Monitor admission controller activity for unexpected reads or writes to resources outside the policy's namespace.
- Enforce policy validation and least-privilege authorization checks in development and deployment workflows.
