GPU VulnDB

Database/Container, Kubernetes & orchestration

Kyverno: image signature verification accepts certificates with no SAN, bypassing signer pinning

CVSS 7.2CVE-2026-122318Container, Kubernetes & orchestrationcurated

Impact

Kyverno is the admission gate many GPU clusters rely on to ensure only signed images run on expensive nodes. matchCertificateData skips the subject and subjectRegExp checks entirely when the signing certificate carries no Subject Alternative Name, so an attacker who holds any leaf certificate issued by a configured private trust root can sign an arbitrary image, omit the SAN, set the expected Fulcio issuer OID, and have the image admitted as if it matched the pinned signer. The practical result is that a workload image the operator believes is pinned to their build pipeline can be replaced by an attacker-built one that lands on GPU nodes with whatever privileges the workload spec requests. Signature policy failure is quiet: nothing in the cluster reports that the identity check was skipped.

Who can reach it

Network attacker who can push an image reference into a cluster workload and who holds a leaf certificate from one of the trust roots already configured in a verifyImages rule. Requires that credential; no access to the Kyverno controller itself.

What to do

Upgrade Kyverno to 1.19.2 or later and restart the admission controller pods; this is a rolling deployment restart, not a node operation. Until then, review which private trust roots are configured in verifyImages rules and rotate or revoke any leaf certificates from those roots that are not strictly needed, since any one of them is sufficient for the bypass.

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.