CVE-2026-122304 is a critical authorization bypass in Kyverno 1.17.0 through 1.19.1 that lets namespace admins use the cleanup controller's ServiceAccount to read Secrets in other namespaces and modify validatingwebhookconfigurations.
What Is It
The flaw is in Kyverno's cleanup controller, which builds its context loader with a nil policy. Because of this, a namespace admin can create a namespaced CleanupPolicy containing apiCall or globalReference context entries. Those entries run with the cleanup controller's ServiceAccount, not with the namespace admin's own limited permissions.
The weakness is classified as CWE-863 (Incorrect Authorization). VulnCheck disclosed the issue, and NVD published the record on 2026-11-05. NVD lists its status as "Awaiting Analysis."
Why It Matters
Kyverno is often used to enforce namespace boundaries in multi-tenant Kubernetes clusters. This bug breaks that boundary. According to the record, an attacker who already has namespace admin rights can:
- Read Secrets in other namespaces using the cleanup controller's ServiceAccount.
- Modify validatingwebhookconfigurations, which are cluster-level admission settings.
VulnCheck rates it CVSS 3.1 9.9 (Critical) with vector AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H: network-reachable, low complexity, low privileges required, no user interaction, and a changed scope. The CVSS 4.0 score is 9.4 (Critical), with high impact on both the vulnerable system and subsequent systems.
The CISA KEV catalog has no entry for this CVE, so there is currently no KEV confirmation of active exploitation.
What's Vulnerable
- Product: Kyverno (
pkg:golang/github.com/kyverno/kyverno) - Affected: 1.17.0 up to but not including 1.19.2
- Unaffected: 1.19.2
The record lists no affected CPEs yet.
Patch Status
The record marks Kyverno 1.19.2 as unaffected. Clusters running 1.17.0 through 1.19.1 should upgrade to 1.19.2 or later. Because the CVE is not in the KEV catalog, CISA has issued no required action or due date. Until you upgrade, check who holds namespace admin rights in clusters running affected versions. The issue requires only low privileges, so every namespace admin should be treated as a possible attacker.