Kyverno v1.19.2 landed October 20 with 26 security advisories resolved — 11 of them critical. The headliner is CVE-2026-122310, a CVSS 9.9 path traversal flaw that hands effective cluster-admin access to any namespace-scoped user who can create a Policy. If you run a shared Kubernetes cluster and haven’t patched yet, that’s not a theoretical risk. It’s an open door.
The Bug That Breaks the Blast Radius
CVE-2026-122310 is subtle and nasty. Kyverno validates the URL in a Policy’s context.apiCall.urlPath after sanitizing it — but then executes the original, unsanitized path. The Kubernetes API client strips # and ? characters before making the actual call, so an attacker can embed ../ sequences behind those characters to slip past the validator. The request lands on a cluster-scoped endpoint using Kyverno’s own ServiceAccount, which carries permissions equivalent to cluster-admin.
The required permissions to exploit this: the ability to create a namespaced Policy. In multi-tenant clusters, that’s a standard developer permission. No special access, no existing cluster privileges — just a crafted Policy object and the keys to the kingdom.
Namespace Isolation? Also Broken
Two more critical bugs target the same surface area: namespace boundary enforcement.
CVE-2026-122311 lets CEL-based namespaced policies escape their namespace entirely and read or write arbitrary cluster objects. If you’ve adopted the newer CEL policy types introduced in 1.18, you’re specifically exposed.
CVE-2026-4789 exploits an inconsistency in Kyverno’s CEL libraries. The resource.Lib enforces namespace parameters; the http.Lib does not — no blocklists, no scoping, no validation of destination. A namespaced policy with http.Get or http.Post can call any service the Kyverno pod can reach: internal cluster services, cloud metadata APIs, anything on the network. The fix disables CEL HTTP functions in namespaced policies by default.
Three separate paths to namespace escape, all patched in 1.19.2.
Twenty-Six Advisories at Once: What That Actually Means
The volume looks alarming — 11 critical, 14 high, 1 moderate, all in one release. It isn’t random breakage. Kyverno graduated from the CNCF in March 2026, and graduation requires a third-party security audit. This batch is largely the result of that audit. The Nirmata release post acknowledges as much. It’s a sign that the process works, not evidence the project is broken.
Other notable fixes include CVE-2026-122321 (image verification signature bypass via TOCTOU — cached results are keyed by image reference, not bound to the verified digest) and CVE-2026-122322/122323 (zip bomb DoS in notary signature layer decompression). The image verification issues matter if your cluster enforces supply chain policy.
1.18 Is Unsupported. Full Stop.
The less-headlined change is the one that will catch teams off guard. Kyverno switched from N-2 to a “main + 1” community patch support model. The current minor release (1.19) gets patches; everything older does not. Version 1.18 is now unsupported. You will not receive security fixes for it.
The maintainers cited an “AI-driven increase in security issues and PRs” as the reason for narrowing the support window. That’s honest: maintaining multiple minor branches under this volume of security reports is not sustainable. But it means anyone on 1.18 — which only shipped in April 2026 — is already without a safety net.
How to Upgrade
The upgrade path is a standard Helm chart bump. Helm chart 3.9.2 ships Kyverno v1.19.2.
helm repo update
helm upgrade kyverno kyverno/kyverno --namespace kyverno --version 3.9.2
# Verify pods are running the patched version
kubectl get pods -n kyverno
kubectl describe pod -n kyverno -l app.kubernetes.io/name=kyverno | grep Image:Two things to check before you run it. First, if you delegate certificate management to cert-manager, verify that certificate rotation still works after the upgrade. Second, the 3.9.0 chart moved per-controller nodeSelector overrides to global values; if you have custom scheduling constraints in your values file, review them before upgrading from anything older than 3.9.0.
After upgrading, audit any namespaced policies that use http.Get or http.Post via CEL — those functions are now disabled by default. If your policies depend on them, you’ll need to explicitly opt in.
The full advisory list lives on the Kyverno GitHub security advisories page. The official upgrade documentation covers edge cases for air-gapped environments and HA configurations. Orca Security also published a detailed technical breakdown of the SSRF vulnerability worth reading before you finalize your remediation plan.
