Kyverno is a Kubernetes policy engine that admits or rejects workloads and can also mutate, generate and clean up cluster objects. On 20 October 2026 the project released version 1.19.2. According to its release notes, the release fixes 24 Kyverno vulnerabilities published as GitHub security advisories, 9 of them Critical and 14 High.
On 5 November 2026 NVD published 21 Kyverno CVE records, all assigned by the CNA VulnCheck and all marked Received. Seven of them score 9.0 or higher on CVSS 3.1. This post compares those seven, then groups the other fourteen so you can see what else the upgrade closes.
Which Seven Kyverno Vulnerabilities Score Critical?
Six of the seven let a user with rights inside one namespace act with Kyverno’s own service accounts, which hold far wider permissions. The seventh bypasses image signature checks. The table follows the NVD records, and the CVSS columns show the CNA’s 3.1 and 4.0 scores. The ranges are the CNA’s; the GitHub advisories for CVE-2026-122303, -122311 and -122313 give different bounds, so upgrade whichever version you run.
How Do You Read This Table?
The “who can exploit” column matters more than the score. Six rows need the right to create a policy object in a namespace. CVE-2026-122310 and CVE-2026-122311 turn that right into cluster-wide reads and writes through path tricks, while CVE-2026-122303 and CVE-2026-122313 abuse the target expression of a mutate-existing policy.
If only cluster administrators can create Kyverno policies in your clusters, these rows are harder to reach. In clusters where teams or customers share the control plane, the namespace boundary is the one that fails. That reading is ours, not the advisories’.
The NVD vector for CVE-2026-122302 lists no privileges required, while the NVD text and the GitHub advisory describe a namespace admin. The advisory rates it High, NVD’s CNA entry rates it 9.8. Treat it as exploitable by namespace admins until Kyverno says otherwise.
What Does the Image Verification Bypass Change?
CVE-2026-122321 affects the verifyImages cache. The advisory says the cache key uses the image reference, such as a tag, and does not bind the result to the verified digest. An attacker who can reference a tag and move it in a registry can warm the cache with a signed image, repoint the tag, and have the workload admitted.
The advisory credits the reporter 1seal and gives CVSS 3.1 9.1 for versions 1.18.0 through 1.19.1. Our advice is to pin digests in production manifests, so a moved tag cannot change what runs. Signature checks only help when the digest you run is the digest that was signed.
What Else Does 1.19.2 Fix?
The other fourteen records score between 6.2 and 8.5 on CVSS 3.1. None reaches the critical band, but five of them need no privileges at all.
| Group | CVE ids | CVSS 3.1 range | Needed to trigger |
|---|---|---|---|
| Cross-namespace read or write | 122308, 122312, 122316, 122320 | 7.7 to 8.5 | A namespaced policy author or a user who can create labelled objects |
| Policy or signature bypass | 122307, 122315, 122318 | 7.5 to 7.7 | PolicyException rights, a crafted OCI referrer, or a leaf certificate from a configured private trust root |
| Denial of service | 122305, 122306, 122309, 122314, 122319, 122322, 122323 | 6.2 to 7.7 | Low privileges, or none for the 122314, 122319, 122322 and 122323 records |
CVE-2026-122314, CVE-2026-122315, CVE-2026-122319, CVE-2026-122322 and CVE-2026-122323 carry no privilege requirement in the NVD vector. Several can crash or exhaust the admission webhook, and two NVD texts say a crash can turn into a policy bypass under failurePolicy Ignore. Check that setting on your clusters.
What Should Platform Teams Do First?
- List every Kyverno install and its version. The Helm chart for this release is 3.9.2, according to the release notes.
- Upgrade to 1.19.2. The release notes direct readers to upgrade and name no workaround.
- List who can create Policy, NamespacedMutatingPolicy, NamespacedValidatingPolicy, CleanupPolicy and PolicyException objects. Remove the right from anyone who does not need it, following least privilege.
- Review existing namespaced policies for apiCall paths containing
#,?or.., mutate-existing targets that name other namespaces, and generate rules aimed at other namespaces. - Check recent changes to RoleBindings, ClusterRoleBindings and validating webhook configurations in the Kubernetes audit log, since those are the objects the flaws let a tenant reach.
Steps 3 to 5 are our advice. The abuse maps to Exploitation for Privilege Escalation and, once a tenant holds a cluster role, Valid Accounts. For ordering the upgrade across clusters, see our patch management glossary entry.