Kyverno 1.19.2 Security Release: 26 Advisories Fixed

Kyverno 1.19.2 fixes 26 security advisories: 11 critical, 14 high and 1 moderate. The worst let a tenant who can create a namespaced policy act across the cluster with Kyverno’s ServiceAccount, up to cluster admin. Others bypass image verification. Upgrade to 1.19.2 (Helm chart 3.9.2); 1.18 is no longer supported in the community.

At a glance

Who is affected?

Almost every Kyverno install is affected, but how exposed you are depends on who can do what in the cluster.

The 11 critical findings mostly assume a tenant who can create namespaced Kyverno policies: Policy, CleanupPolicy, NamespacedMutatingPolicy, NamespacedValidatingPolicy and their relatives. Platforms that hand namespaces to teams and let them write their own policies are the exposed case. That is the multi-tenant setup the namespaced policy types exist for.

A second group needs much less. Forging the annotation that carries image verification results, spoofing Kyverno’s internal generate labels, and crashing the policy engine with a crafted resource all need only the right to create a resource. The image verification flaws can be triggered by whoever controls an image’s tags, signatures or attestations.

The patched version is the same everywhere: 1.19.2. Two advisories name 1.11 as the earliest affected release, and none has a backport to an older minor line. The Kyverno community patch policy supports only the current minor release, 1.19.

What did Kyverno 1.19.2 fix?

The release notes group the 26 advisories into eight areas. The table below follows the same grouping, with the two late advisories added.

Namespace confinement

Namespaced policies only make sense if they stay inside their namespace. Eight of the critical findings break that, and a ninth (GHSA-vjfx-fp68-rh4v) does it through generate rules. One example: a namespaced Policy’s apiCall.urlPath could hide .. segments behind a query string (GHSA-3xfv-vq8x-qhg4). A tenant’s CEL policy could put a path traversal in the resource argument of resource.get() (GHSA-4pqm-wqq6-h9q2). In each case the request ran with Kyverno’s own ServiceAccount, which can read across namespaces and, in the worst cases, create cluster-scoped admission webhooks. From there the path to cluster admin is short.

GHSA-39w8-hv5g-f73w deserves its own note. Version 1.19.1 added a namespace check to apiCall to close two earlier advisories. That check read a decoded copy of the path but sent the raw one, and a malformed percent-escape such as ?a=% made the two disagree. If you upgraded to 1.19.1 in September for those fixes, the hole was still open.

Image verification

Six advisories cover verifyImages and notary. In the most serious (GHSA-2r43-6962-xcw5), results were cached by tag rather than digest, so moving a tag after one good check could get an unverified image admitted. Another skipped the cosign subject check when the signing certificate had no Subject Alternative Name (GHSA-fcfr-fr8g-qjqv). A third let a user forge the annotation that records a successful verification (GHSA-h3pm-q9ww-f439). If you rely on Kyverno to keep unsigned images out, treat this group as critical whatever the label says.

Generate, exceptions and denial of service

Generate rules had two authorization gaps. The admission check asked whether Kyverno could create the target, not whether the policy author could (GHSA-q62c-r9v2-cf64). It also skipped the check entirely when the target kind was a variable (GHSA-vjfx-fp68-rh4v). Separately, when Kyverno generated ValidatingAdmissionPolicies from its own policies, it folded in PolicyExceptions without checking the usual exception settings (GHSA-qc9c-3fgf-cgq8). The remaining fixes bound wildcard matching, variable substitution and CEL cost, and stop panics. Each of those could take down the shared admission webhook. A crash is worse than an outage when the webhook runs with failurePolicy: Ignore, because requests are then admitted without policy checks.

How do I check my clusters?

1. Find the version that is actually running. The image tag is what counts, not the chart you think you installed.

   kubectl get pods -n kyverno -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.containers[*].image}{"\n"}{end}'

2. List the namespaced policies that exist, and note who created them.

   kubectl get policies.kyverno.io,cleanuppolicies.kyverno.io -A
   kubectl get namespacedmutatingpolicies,namespacedvalidatingpolicies,namespacedgeneratingpolicies,namespaceddeletingpolicies,namespacedimagevalidatingpolicies -A

3. Check which users and service accounts can create them. Repeat for each tenant identity and for the other namespaced kinds.

   kubectl auth can-i create policies.kyverno.io -n team-a --as=system:serviceaccount:team-a:deployer
   kubectl auth can-i create cleanuppolicies.kyverno.io -n team-a --as=system:serviceaccount:team-a:deployer

4. Check the webhook failure policy. Ignore turns any of the crash bugs into a policy bypass.

   kubectl get validatingwebhookconfigurations,mutatingwebhookconfigurations -o custom-columns=NAME:.metadata.name,POLICY:.webhooks[*].failurePolicy | grep -iE 'NAME|kyverno'

What if I can’t upgrade today?

The only full fix is 1.19.2. Until you can get there, these steps shrink the blast radius:

• Remove create and update rights on every namespaced Kyverno policy kind from tenant roles. Treat them as cluster-admin-adjacent permissions until you are on 1.19.2.
• Review existing namespaced policies for apiCall entries, resource.get() or resource.post() calls, and mutate-existing or generate targets whose namespace or kind comes from a variable.
• Pin images by digest in workloads that depend on image verification, so the tag-caching bypass has nothing to move.
• Watch kube-system and other sensitive namespaces for new RoleBindings, webhook configurations and NetworkPolicies you didn’t create.

How do I upgrade to Kyverno 1.19.2?

For Helm installs, chart 3.9.2 ships Kyverno v1.19.2:

helm repo update helm upgrade kyverno kyverno/kyverno -n kyverno --version 3.9.2

If you are on 1.18 or older, this is a minor-version upgrade. Read the 1.19.0 release notes and test your policies against 1.19 first. For upgrade planning, see the Kyverno Operators Playbook.

For Kyverno managed through Nirmata, use the add-on upgrade option in the console.

For Nirmata Enterprise for Kyverno customers, Nirmata will be providing patched images for the Enterprise releases they are running currently as per the Enterprise SLA. Please reach out to us at customer-success@nirmata.com for specific release information.

Nirmata engineers wrote several of these fixes, and some began in Nirmata Enterprise for Kyverno before being contributed back to open source. Nirmata Enterprise for Kyverno provides hardened builds and backports security fixes to older minor releases, for teams that can’t move to the newest minor every time a fix lands.

All 26 advisories

CVE IDs have been requested for these advisories and will be added to each one when they are assigned. Affected ranges are copied from each GitHub advisory. Where an advisory gives no CVSS score, the column shows a dash. Some ranges stop before 1.19.1, but every advisory lists 1.19.2 as its only patched release, so read the advisory itself before deciding a row doesn’t apply to you.

Related reading

• Kyverno Runs Your Admission Control. Is It Actually Hardened? covers the configuration choices that limit the damage from bugs like these.
• Critical Kyverno Vulnerability — CVE-2026-54523, the earlier NamespacedMutatingPolicy escape fixed in 1.18.2.
• Kyverno Security Advisory: Cross-Namespace Privilege Escalation, the January apiCall fix that several of these findings build on.
• Kyverno OSS and the Production Kyverno Assessment.