GPU VulnDB

Database/Container, Kubernetes & orchestration

Kyverno: apiCall urlPath is validated after cleaning but executed raw, reaching cluster-scoped endpoints

CVSS 9.4CVE-2026-122310Container, Kubernetes & orchestrationcurated

Impact

Kyverno validates a Policy's context.apiCall urlPath after normalising it, but executes the raw string; the Kubernetes client then discards the fragment or query portion. A tenant can hide ../ segments behind a # or ? so the validated path looks namespace-confined while the executed request reaches cluster-scoped endpoints with Kyverno's own ServiceAccount, which is effectively cluster admin. On a shared GPU cluster this takes a single namespace-scoped tenant to full control of the control plane: read every secret, mutate RBAC, reach any tenant's workloads and nodes. The admission controller is the trust boundary here, so there is no second layer behind it.

Who can reach it

An authenticated tenant who can create a Policy in one namespace. Kubernetes API access only - no node or GPU access required.

What to do

Upgrade Kyverno from 1.19.1 to 1.19.2 or later per the GitHub advisory. Controller rollout and pod restart; no node drain, no GPU workload impact beyond a brief admission gap during the rolling restart. Interim mitigation: deny tenants the ability to create Policy objects, or block policies that use context.apiCall.

References

Related entries

All Container, Kubernetes & orchestration entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.