Kyverno Runs Your Admission Control. Is It Actually Hardened?
Updated Ritesh Patel
To harden Kyverno, run its admission webhooks fail-closed, enforce image verification for every registry, sign policy bundles and re-verify them on each cluster, and keep write access to ClusterPolicy, PolicyException and webhook configurations tight. The Kyverno End User Threat Model and Hardening Guide, from CNCF, ControlPlane and the Kyverno maintainers, sets out 17 such recommendations.
At a glance: the guide’s high-severity findings and the hardened setting
| Finding | Risky configuration | Hardened configuration |
|---|---|---|
| Fail-open admission webhooks | failurePolicy: Ignore or --forceFailurePolicyIgnore |
Fail-closed webhooks |
| Unverified images at admission | verifyImages in failureAction: Audit, or not covering every registry |
Image verification enforced for every registry |
| Unsigned policy distribution | Policy bundles stored and consumed without signatures | Bundles signed with cosign and re-verified on every consuming cluster |
| RBAC and PolicyException sprawl | Broad write access to ClusterPolicy, PolicyException or webhook configurations |
Least-privilege RBAC on cluster-scoped resources |
Kyverno sits in a uniquely privileged spot in your cluster: every workload request passes through it before the API server ever sees it. That’s what makes it such an effective policy engine. It’s also why a misconfigured Kyverno deployment doesn’t just weaken one control. It can quietly remove your entire enforcement layer.
This isn’t hypothetical. Earlier this year, CVE-2026-54523 (CVSS 9.6) showed how a boundary gap in Kyverno’s policy engine let a namespace-scoped user with policy-creation permissions generate resources in namespaces they had no business touching: a cluster-wide privilege escalation path from a single missing check. It was fixed fast, in Kyverno 1.18.2. But the underlying lesson wasn’t really about that one bug. A component this privileged will always reward attackers who go looking for the misconfiguration, not just the CVE.
Is AI finding vulnerabilities faster than teams can patch them?
The misconfiguration risk above is only half the picture. AI-assisted research has changed the pace of open-source vulnerability discovery. Palo Alto Networks’ AI-driven scanning system found more than 14,000 previously unknown vulnerabilities across roughly 3,900 open-source projects in just two months. Traditional fuzzing infrastructure like OSS-Fuzz took years to reach that volume. Monthly CVE disclosures have jumped 145% over the last two years.
Frontier models built with real offensive-security capability, Anthropic’s own Claude Fable and its successor Mythos among them, are a big part of why. The same capability that helps defenders find and fix bugs faster also means vulnerabilities in widely used projects surface faster than most teams can triage and patch them.
That changes the math on how you run any privileged, security-critical component like Kyverno. Average patch cycles still run around 55 days. The gap between disclosure and remediation is exactly the window an admission-control bypass can exploit.
Which serious Kyverno CVEs surfaced in 2026?
Kyverno itself hasn’t been immune to this acceleration. Between January and July 2026, three serious CVEs surfaced: CVE-2026-22039 (Critical, CVSS 9.9, an authorization bypass breaking namespace isolation via the apiCall context), CVE-2026-4789 (rated High, 8.5, in Kyverno’s GitHub advisory and 9.8 by CISA-ADP; an SSRF via the CEL http.Lib function), and CVE-2026-54523 (Critical, CVSS 9.6, the cross-namespace resource-creation bug above). Three serious findings in one widely deployed admission controller, inside half a year, is the pattern the broader AI-driven research surge predicts.
| CVE | Component | Severity (CVSS 3.1) | Affected | Fixed |
|---|---|---|---|---|
| CVE-2026-22039 | Namespaced Policy apiCall |
Critical, 9.9 | Before 1.15.3; 1.16.0 to 1.16.2 | 1.15.3, 1.16.3 |
| CVE-2026-4789 | CEL http.Get / http.Post in namespaced policies |
High, 8.5 (GitHub advisory); Critical, 9.8 (CISA-ADP on NVD) | 1.16.0 to 1.17.1 | 1.16.4, 1.17.2 |
| CVE-2026-54523 | NamespacedMutatingPolicy generator.apply() |
Critical, 9.6 | 1.18.0, 1.18.1 | 1.18.2 |
Hardening the configuration around Kyverno (fail-closed webhooks, signed and verified policies, tight RBAC) doesn’t just protect you today. It’s a fallback for the vulnerabilities that get found faster than any team can patch them. See all Kyverno security advisories.
What is the Kyverno End User Threat Model and Hardening Guide?
That’s the gap the Kyverno End User Threat Model and Hardening Guide sets out to close. It’s a joint effort between the Cloud Native Computing Foundation, security consultancy ControlPlane, and the Kyverno maintainer community. Nirmata’s own Jim Bugwadia and Shuting Zhao are among the reviewers, alongside ControlPlane’s Samuel Holmes and Tom Cope, CEO Andrew Martin, and fellow reviewers Tom Holtby and Mike Bryant.
The guide threat-models Kyverno the way you’d threat-model any component sitting on your cluster’s trust boundary. It gives CIA-based risk ratings for every controller, defines threat actors and their realistic attack paths, and uses attack trees to show how small misconfigurations chain into real compromises. It covers both single-cluster and multi-cluster hub-and-spoke deployments. It lands 13 findings and 17 hardening recommendations, each mapped to MITRE ATT&CK and NIST SP 800-53. That’s the kind of artifact your security team can take into an audit.
We’re not going to try to replace it here. Go download the guide and read it properly. What we want to do is make the case for why it’s worth your time, and where it fits into how you run Kyverno day to day.
Why does this matter if you’ve “already hardened” Kyverno?
A few of the guide’s high-severity findings are worth discussing, because they’re easy to introduce by accident and easy to miss in a review:
- Fail-open admission webhooks. Set
failurePolicy: Ignore(or the--forceFailurePolicyIgnoreflag), and any Kyverno outage, whether a crash, resource exhaustion or a bad rollout, means workloads are admitted with zero policy evaluation. Availability quietly becomes your security control. Worse, an attacker doesn’t need to touch Kyverno at all; exhausting resources in thekyvernonamespace from a tenant workload is enough to trigger the bypass. - Unsigned or unverified images at admission. A
verifyImagesrule left infailureAction: Audit, or simply not covering every registry your images come from, means unsigned or tampered images ship straight to production without a single cryptographic check. - Unsigned policy distribution. If your policy bundles aren’t signed with cosign before storage and re-verified on every consuming cluster, a single compromised registry write can tamper with enforcement across your entire fleet, not just one cluster.
- RBAC and PolicyException sprawl. Broad write access to
ClusterPolicy,PolicyException, or webhook configuration resources means anyone with that access can quietly carve out exemptions from the rules everyone else has to follow.
How do you use the guide to harden Kyverno?
None of these findings require a Kyverno vulnerability. They’re all configuration choices, often defaults chosen for ease of installation rather than production security, as the guide’s own maintainer preface points out. That’s why a document like this exists: strong policies don’t mean much if the webhook behavior is fail-open, the RBAC is overly broad, or nobody’s reviewing what gets promoted from audit mode to enforce.
Treat the guide as a working checklist, not a document to file away. Read the CIA impact assessment against your own architecture, single cluster or hub-and-spoke, and be honest about which of the 13 threats apply to how you’re running Kyverno today. Then work through the R-ARCH, R-RBAC, R-POLICY, R-NETWORK, and R-MONITORING recommendation sets in priority order. The high-severity ones (webhook failure policy, image verification enforcement, policy bundle signing, least-privilege RBAC on cluster-scoped resources) are the findings above. Fix those first.
How does Nirmata Enterprise for Kyverno help keep Kyverno hardened?
Hardening Kyverno isn’t a one-time project. It’s ongoing work against a moving target: new CVEs, new Kubernetes versions, policy drift as your platform team scales. That’s why we built Nirmata Enterprise for Kyverno (N4K). It gives you secure-by-default configuration out of the box and direct access to the same Kyverno maintainers who helped write this guide. CVE fixes are backported to older release branches, including branches no longer actively maintained upstream, so you’re not forced into a disruptive upgrade just to stay patched. That backport coverage is also something a hardened base-image vendor can’t provide on its own: an image vendor like Chainguard repackages the upstream Kyverno release it tracks, so if a fix hasn’t been backported to your branch upstream, it isn’t in that vendor’s image for that branch either.
If you’re running open-source Kyverno today, three resources are worth bookmarking alongside the guide itself:
- Enterprise Kyverno release notes: see exactly which CVEs are fixed and backported in each release.
- Enterprise Kyverno long-term support matrix: know how long your version stays supported before you’re planning an upgrade under pressure.
- The full Kyverno End User Threat Model and Hardening Guide: the checklist for Kyverno Hardening.
Our thanks again to CNCF, ControlPlane, and the whole Kyverno maintainer community for putting this together. It’s the kind of rigor that comes with Kyverno’s CNCF Graduated status, and it makes the entire ecosystem safer, whether you run it yourself or run it with us.
Related reading
- Critical Kyverno Vulnerability: CVE-2026-54523 covers the vulnerability, the fix and the interim mitigations.
- See all Kyverno security advisories.
- Get a second opinion on your own deployment with a Production Kyverno Assessment, or browse the Kyverno playbook.
Frequently asked questions
Does hardening Kyverno replace patching its CVEs?
No. CVE-2026-22039, CVE-2026-4789 and CVE-2026-54523 were bugs in Kyverno's own code, and only an upgrade removes them. Hardening narrows who can reach those code paths and limits what a successful attack can touch. CERT/CC's note on CVE-2026-4789, for example, recommends default-deny network policies on the Kyverno admission controller pod to block unexpected egress.
What permission did the 2026 Kyverno CVEs require?
Each one needed only the right to create a namespaced Kyverno policy: a namespaced Policy with an apiCall for CVE-2026-22039, a NamespacedValidatingPolicy using CEL http functions for CVE-2026-4789, and a NamespacedMutatingPolicy for CVE-2026-54523. That is why the right to create namespaced policies deserves the same review as access to cluster-scoped Kyverno resources.
How was CVE-2026-4789 fixed?
The Kyverno 1.16.4 and 1.17.2 release notes list a backported change that disables HTTP calls in namespaced policies by default, referencing CVE-2026-4789. The GitHub advisory GHSA-rggm-jjmc-3394 names 1.16.4 as the patched version. On 1.16.0 to 1.16.3 and 1.17.0 to 1.17.1, those http.Get and http.Post calls from namespaced policies are unrestricted.
Why do sources give CVE-2026-4789 different severity scores?
Kyverno's GitHub advisory scores it 8.5 (High), assuming an attacker needs low privileges to create a namespaced policy. The CISA-ADP score shown on NVD is 9.8 (Critical), with a vector that assumes no privileges are required. Both describe the same SSRF in the CEL http library, so check which score your scanner reports before you compare findings across tools.