GPU VulnDB

Database/Container, Kubernetes & orchestration

Kyverno: unchecked type assertion in shallow variable substitution panics the policy engine

CVSS 8.7CVE-2026-122314Container, Kubernetes & orchestrationcurated

Impact

Any principal that can submit a resource the policy engine evaluates can include a non-string field where a policy uses {{- variable }} shallow substitution, panicking the engine. On a GPU cluster Kyverno is usually the thing enforcing the rules that keep tenants apart - which images may run, whether a pod may ask for privileged mode, hostPath, or the host devices that expose GPUs. With failurePolicy: Ignore the panic turns into a policy bypass: the admission request is admitted unchecked, so a tenant can land a pod that policy would have refused. With failurePolicy: Fail it is instead a cluster-wide denial of service, blocking every scheduling decision until the webhook recovers.

Who can reach it

Anyone who can submit a resource that the Kyverno webhook evaluates - in practice any tenant with namespace-level create permission on a GPU cluster. NVD records PR:N (no authentication) for the vector; the practical requirement is API access to the cluster.

What to do

Upgrade Kyverno to 1.19.2 or later. This is a controller deployment rollout: patch the chart/image and restart the admission and reports controllers; no node drain or reboot. Until you can upgrade, review which policies use {{- ... }} shallow substitution and whether your webhooks run with failurePolicy: Ignore - Ignore converts the crash into a silent policy bypass and is the riskier of the two settings here.

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.