Summary
Kyverno's APICall Fetch() can bypass namespace isolation when URL path validation interprets query-string content differently from the Kubernetes client. A user who can create namespaced policies may be able to read cluster-scoped resources outside their namespace.
Kyverno's APICall Fetch() can bypass namespace isolation when URL path validation interprets query-string content differently from the Kubernetes client. A user who can create namespaced policies may be able to read cluster-scoped resources outside their namespace.
Affected context
The issue affects Kyverno's APICall Fetch() path when a namespaced policy supplies a URLPath that is checked for namespace boundaries before being used by client-go. Because path.Clean treats ? as a path character, namespace-like segments in a query string can influence validation even though the client interprets the URL differently. The risk depends on policy creation permissions and the resources accessible to the Kyverno service account.
The issue affects Kyverno's APICall Fetch() path when a namespaced policy supplies a URLPath that is checked for namespace boundaries before being used by client-go. Because path.Clean treats ? as a path character, namespace-like segments in a query string can influence validation even though the client interprets the URL differently. The risk depends on policy creation permissions and the resources accessible to the Kyverno service account.
Exploit preconditions
- Attack surface: APICall Fetch() in the Kyverno policy engine
- Required access: Permission to create namespaced policies
- Trigger point: Evaluation of a policy containing a crafted URLPath
- Why exploitation is possible: Validation and request handling interpret the path and query string differently, potentially allowing a cluster-scoped request to pass namespace checks
- Attack surface: APICall Fetch() in the Kyverno policy engine
- Required access: Permission to create namespaced policies
- Trigger point: Evaluation of a policy containing a crafted URLPath
- Why exploitation is possible: Validation and request handling interpret the path and query string differently, potentially allowing a cluster-scoped request to pass namespace checks
Why this happens
The underlying issue is an authorization boundary check performed on a path representation that does not match how the HTTP client interprets the request. path.Clean treats ? as an ordinary path character, so namespace validation can match segments inside what the client later treats as a query string. This is an authorization and privilege-boundary failure associated with CWE-269: Improper Privilege Management.
The underlying issue is an authorization boundary check performed on a path representation that does not match how the HTTP client interprets the request. path.Clean treats ? as an ordinary path character, so namespace validation can match segments inside what the client later treats as a query string. This is an authorization and privilege-boundary failure associated with CWE-269: Improper Privilege Management.
Potential impact
- A policy creator could read resources outside their namespace
- Sensitive cluster-scoped resource data could be exposed
- Exposed information could support further attacks against the cluster
- A policy creator could read resources outside their namespace
- Sensitive cluster-scoped resource data could be exposed
- Exposed information could support further attacks against the cluster
General mitigation guidance
Mitigation patterns focus on validating the exact request that will be made and keeping authorization checks aligned with request parsing.
- Parse URLs with a standards-aware URL parser and validate the parsed path separately from the query
- Restrict APICall requests to explicitly allowed paths and resource scopes
- Enforce authorization against the resolved target resource, not a separately normalized string
- Limit policy creation permissions and run Kyverno with only the privileges it needs
- Prefer secure-by-default APIs that disallow cluster-scoped access from namespaced policies unless explicitly authorized
Mitigation patterns focus on validating the exact request that will be made and keeping authorization checks aligned with request parsing.
- Parse URLs with a standards-aware URL parser and validate the parsed path separately from the query
- Restrict APICall requests to explicitly allowed paths and resource scopes
- Enforce authorization against the resolved target resource, not a separately normalized string
- Limit policy creation permissions and run Kyverno with only the privileges it needs
- Prefer secure-by-default APIs that disallow cluster-scoped access from namespaced policies unless explicitly authorized
How teams detect issues like this
- Review URL and path validation for checks performed before or independently of URL parsing
- Use static analysis and code review to flag path normalization used as an authorization control
- Test policy evaluation with query strings and path segments that could affect scope checks
- Apply admission policies that restrict who can create APICall policies and which targets they may access
- Review URL and path validation for checks performed before or independently of URL parsing
- Use static analysis and code review to flag path normalization used as an authorization control
- Test policy evaluation with query strings and path segments that could affect scope checks
- Apply admission policies that restrict who can create APICall policies and which targets they may access
