Critical Kyverno Vulnerability — CVE-2026-54523

28 July 2026

Critical Kyverno Vulnerability — CVE-2026-54523

Screenshot 2026 07 28 at 6.02.02 PM

Critical Kyverno Vulnerability — CVE-2026-54523

On July 13, 2026, a critical vulnerability was disclosed in Kyverno, the Kubernetes-native policy engine used broadly across the cloud native ecosystem for policy-as-code enforcement. The vulnerability, tracked as CVE-2026-54523 (GHSA-79gf-7frw-68m9), allows a tenant with permission to create a NamespacedMutatingPolicy in their own namespace to bypass namespace isolation entirely and generate resources anywhere in the cluster — including kube-system. This impacts only release 1.18.0 and 1.18.1 and it patched in 1.18.2. 

This is rated Critical, CVSS 3.1 score 9.6 (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N) — network-exploitable, low attack complexity, only low privileges required, no user interaction needed.

Kyverno Vulnerability Details

The root cause sits in Kyverno’s nmpol CEL compiler. NamespacedMutatingPolicy resources support a generator.apply(namespace, resources) function inside matchConditions boolean expressions — but the namespace argument isn’t validated against the policy’s own namespace. A tenant who can create a NamespacedMutatingPolicy — normally treated as a routine, namespace-scoped capability — can call generator.apply() with an arbitrary target namespace. Because Kyverno’s admission controller typically runs with cluster-wide RBAC permissions, the generated resources get created wherever the attacker specified.

In practice: a low-privileged tenant could generate a RoleBinding granting themselves cluster-admin access, or tamper with ConfigMaps, NetworkPolicies, or Ingresses outside their own namespace — a complete namespace-isolation bypass and a direct path to cluster-wide privilege escalation.

 

Resolution Options

Kyverno has already released a patch:

Vulnerable: Kyverno =  v1.18.0, v.1.18.1

Patched: Kyverno v1.18.2

We strongly recommend upgrading to v1.18.2 or later as soon as possible.

If you can’t upgrade immediately:

  • Restrict who can create NamespacedMutatingPolicy resources — treat this as a cluster-admin-adjacent permission, not a routine namespace-scoped grant.
  • Audit existing NamespacedMutatingPolicy objects for matchConditions expressions calling generator.apply() with a namespace argument outside the policy’s own namespace.
  • Monitor sensitive namespaces (kube-system and others) for unexpected Role, RoleBinding, ConfigMap, NetworkPolicy, or Ingress activity.

 

Upgrade Options for Nirmata Enterprise for Kyverno (N4K) Customers

For Kyverno managed through Nirmata, use the add-on upgrade option in the console to move to v1.18.2 or later. For self-managed Kyverno installs, upgrade via Helm or by applying updated manifests

helm upgrade kyverno kyverno/kyverno --version <chart version tracking 1.18.2 >

Nirmata’s team is available to help review your NamespacedMutatingPolicy usage and complete this upgrade safely. 

For Nirmata’s Enterprise 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 cs@nirmata.com for specific release information.

The AI Gateway Buyer's Guide: Beyond Routing and Tool Visibility
Kyverno Policy: Migration to CEL Based Policies

Latest

From the blog

The latest industry news, interviews, technologies, and resources.

View all blogs
Introducing the Remediator Agent: Turning Kyverno Policy Violations into Pull Requests, Automatically.
Introducing the Remediator Agent: Turning Kyverno Policy Violations into Pull Requests, Automatically.

The AI Governance Market Is Here. Most of the Problem Remains Unsolved.

Nirmata’s Cloud Agents Audited a 40-Cluster Kubernetes Fleet, and recovered 40% of the Cost
Nirmata’s Cloud Agents Audited a 40-Cluster Kubernetes Fleet, and recovered 40% of the Cost

Nirmata’s Cloud Agents Audited a 40-Cluster Kubernetes Fleet, and recovered 40% of the Cost   Most Kubernetes Cost overruns…