GHSA-8p9x-46gm-qfx2: Kyverno Cross-Namespace Privilege Escalation via Policy apiCall
SummaryA critical authorization boundary bypass in namespaced Kyverno Policy [apiCall](https://kyverno.io/docs/policy-types/cluster-policy/external-data-sources/#url-paths). The resolved `urlPath` is executed using the Kyverno admission controller ServiceAccount, with no enforcement that the request is limited to the policy’s namespace.As a result, any authenticated user with permission to create a namespaced Policy can cause Kyverno to perform Kubernetes API requests using Kyverno’s admission controller identity, targeting any API path allowed by that ServiceAccount’s RBAC. This breaks namespace isolation by enabling cross-namespace reads (for example, ConfigMaps and, where permitted, Secrets) and allows cluster-scoped or cross-namespace writes (for example, creating ClusterPolicies) by controlling the urlPath through context variable substitution.DetailsThe vulnerability exists in how Kyverno handles `apiCall` context entries. The code substitutes variables into the `URLPath` field without sanitizing the output or validating that the resulting path is authorized for the scope of the policy.In `pkg/engine/apicall/apiCall.go`, the `Fetch` method performs variable substitution on the entire `APICall` object, including the `URLPath`.In `pkg/engine/apicall/executor.go`, the `Execute` method delegates to `executeK8sAPICall`, which passes the raw path directly to the Kubernetes client's `RawAbsPath` method.Because `RawAbsPath` executes a direct HTTP request to the API server using Kyverno's admission controller service account (which typically has broad permissions), an attacker can construct any valid API path to access and mutate resources they shouldn't have access to.PoC 001 - Data exfiltrationThe following steps demonstrate how a user restricted to the `default` namespace (with no access to `kube-system`) can read a sensitive ConfigMap from the `kube-system` namespace.**0. Setup kind + Kyverno**Tested with Kyverno v1.16.1 on k8s v1.34.0.**1. Setup target and low-privileged user**
Create a confidential resource in a privileged namespace, and create a restricted user `policy-admin` who only has permissions to manage policies in the `default` namespace.**2. Create malicious policy as the restricted user**
Impersonating the restricted user `policy-admin`, apply a namespaced `Policy` in the `default` namespace.**3. Trigger the leak**
As the restricted user, create a ConfigMap in the `default` namespace with annotations pointing to the target resource in `kube-system`.**4. Result**
The creation request is denied, but the error message contains the secret data from `kube-system`, proving the privilege escalation.PoC 002 - ClusterPolicy injectionContinue from the setup from the previous PoC.This vulnerability also allows creation of cluster-level resources. For example, a low-privileged user can create a `ClusterPolicy` that impacts the entire cluster. In this PoC, a low-privileged user creates a cluster policy, which prevents scheduling of pods.**1. Apply a malicious policy****2. Trigger the policy**This outputs an error:**3. Observe the new cluster policy**Outputs:**4. Verify that no new pods can be created (even as a cluster admin)**Run:Outputs:ImpactUsers with `Policy` creation rights in a single namespace can escalate privileges (context of Kyverno admission controller).Since `apiCall` supports `POST`, attackers can potentially create resources in privileged namespaces (e.g., creating a RoleBinding in `kube-system` to grant themselves cluster-admin) if the Kyverno service account has write permissions.Attackers can disrupt the entire cluster by creating a malicious `ClusterPolicy` that blocks critical operations (e.g., preventing Pod scheduling), as demonstrated in PoC #2.Sensitive data (Secrets, tokens, configuration) can be exfiltrated from any namespace, depending on the RBAC.In shared clusters, one tenant can read data belonging to other tenants or the cluster administration.The following command should be run on a per-environment basis to understand impact:By default, this does not include Secrets.MitigationThe `apiCall` logic should enforce that `Policy` resources (namespaced policies) can only access resources within the same namespace. If a `Policy` attempts to access a resource in a different namespace via `urlPath`, the request should be blocked. `ClusterPolicy` resources are unaffected by this restriction as they are intended to operate cluster-wide.The mitigation logic validates the `urlPath` for namespaced policies by ensuring:The path explicitly contains the `/namespaces/<namespace>/` segment.The namespace in the path matches the policy's namespace.Requests missing the namespace segment (targeting cluster-scoped resources) or targeting a different namespace are rejected.This effectively prevents both the cross-namespace data leak and the creation of cluster-scoped resources (like `ClusterPolicy`) or resources in other namespaces via the `POST` method.
CVSS v3.1: 9.9