Kyverno before 1.19.2 Privilege Escalation via Generate Rule Permission Check
Kyverno before 1.19.2 lets a namespace admin who can create a namespaced Policy make the background controller create or clone resources beyond their RBAC, including in other namespaces or cluster-wide. Fixed in 1.19.2.
Written by anthropic/claude-haiku-5.5 from the sources below. Verify against them.
- Exploited
- No known exploitation
- Fix
- Fixed in 1.19.2
- Who is exposed
- Default setups
Do first: Check every install: default setups are affected.
- Last modified
- FIRST's estimate of the chance attackers exploit it in the next 30 days, updated daily.What do these mean? →
- 0.28% · 21st percentile
- A 0-100 score for how much a CVE matters across the industry: exploitation, exposure, how widely the software is used, severity and whether a fix exists.What do these mean? →
- 31/100 · provisional
- How many real-world setups can hit the bug, from the vendor's advisory and CISA data. It does not know your setup.What do these mean? →
- Default setups
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
Summary
Kyverno contains a privilege escalation flaw that lets an attacker, remotely and without logging in, create resources beyond their permissions. By creating a namespaced Policy with generate rules that target other namespaces or cluster-scoped kinds, the attacker can make the background controller create or clone resources cluster-wide, because the permission check verifies the controller's rights rather than the author's.
Read the original description
Kyverno before 1.19.2 contains a privilege escalation vulnerability that allows namespace admins to create resources beyond their RBAC because generate-rule admission checks verify the controller's permissions, not the author's. Attackers can create a namespaced Policy with generate rules targeting other namespaces or cluster-scoped kinds, making the background controller create or clone resources cluster-wide.
cve.now Index
- Exploitation?/40Unknown. No CISA SSVC exploitation rating yet
- Exposure22/25Default setups, reachable over the network without a login
- Reach?/20Unknown. No tracked technology or package matched
- Severity9.3/10CVSS 9.3
- No patch0/5No signal
What would change the score
- Would score about 71 if added to CISA KEV
- Would score about 66 if CISA's SSVC rates exploitation active
What to do
Check every install: default setups are affected.
Upgrade to a fixed version: 1.19.2.
Timeline
- CVE published
- First seen by cve.now
- Posted on X by cve.now
Affected versions
- kyverno kyverno
fixed in 1.19.2
Evidence 2
- Advisory
- Link
Corrections
None so far.
Something wrong on this page? Report an error. Every fix is listed here.
Questions about CVE-2026-122302
Is CVE-2026-122302 being exploited?
It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked.Source: cve.now feed data
What does this mean?
A namespaced Kyverno Policy with generate rules can target other namespaces or cluster-scoped kinds. The background controller then creates or clones whatever its own RBAC allows, so a namespace admin can get resources beyond their own namespace.Source: vulncheck.com, github.com
Which versions are affected by CVE-2026-122302?
kyverno: before 1.19.2.Source: cve.now feed data
Am I affected, and how do I check?
Kyverno versions before 1.19.2 are affected. The shipped chart RBAC lets every namespace admin create a namespaced Policy, so the check is the Kyverno version an installation runs, such as the image tag of the Kyverno deployment.Source: vulncheck.com, github.com
How do I fix CVE-2026-122302?
Upgrade Kyverno to 1.19.2, which is the fixed version.Source: vulncheck.com, github.com