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 exactly what makes it such an effective policy engine — and exactly 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. It’s that a component this privileged will always reward attackers who go looking for the misconfiguration, not just the CVE.
AI is finding vulnerabilities faster than most teams can patch them
The misconfiguration risk above is only half the picture. AI-assisted research has fundamentally 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 — a volume that took traditional fuzzing infrastructure like OSS-Fuzz years to reach. Monthly CVE disclosures have jumped 145% over the last two years.
Kyverno itself hasn’t been immune to this acceleration. In the six months from February to July 2026 alone, three separate critical-severity CVEs surfaced: CVE-2026-22039 (CVSS 10.0, an authorization bypass breaking namespace isolation via the apiCall context), CVE-2026-4789 (CVSS 9.8, an SSRF via the CEL http.Lib function), and CVE-2026-54523 (CVSS 9.6, the cross-namespace resource-creation bug above). Three critical findings in one widely-deployed admission controller, inside half a year, is exactly the pattern the broader AI-driven research surge predicts.
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; that gap between disclosure and remediation is exactly the window an admission-control bypass can exploit. 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.
A new guide, built by the people closest to the problem
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 — including Nirmata’s own Jim Bugwadia and Shuting Zhao 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: CIA-based risk ratings for every controller, defined threat actors and their realistic attack paths, attack trees showing how small misconfigurations chain into real compromises, and coverage of 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 — the kind of artifact your security team can actually 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 actually run Kyverno day to day.
Why this matters even 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 — a crash, resource exhaustion, 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.
None of these 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 precisely 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.
How to actually use it
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 actually 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 exactly the findings above, and they’re the ones worth fixing first.
Beyond the checklist
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 exactly why we built Nirmata Enterprise for Kyverno (N4K): secure-by-default configuration out of the box, CVE fixes 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, and direct access to the same Kyverno maintainers who helped write this guide. 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 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.
