Critical Kyverno Vulnerability — CVE-2026-54523

CVE-2026-54523 is a critical Kyverno vulnerability (CVSS 9.6) that lets a tenant who can create a NamespacedMutatingPolicy generate resources in any namespace, including kube-system. It affects Kyverno 1.18.0 and 1.18.1 and is fixed in 1.18.2. If you can’t upgrade yet, restrict who can create NamespacedMutatingPolicy resources and audit the ones that exist.

At a glance

CVE	CVE-2026-54523 (GHSA-79gf-7frw-68m9)
Component	Kyverno NamespacedMutatingPolicy CEL compiler, generator.apply()
Severity	Critical, CVSS 3.1 score 9.6
Affected	Kyverno 1.18.0 and 1.18.1
Fixed	Kyverno 1.18.2
Mitigation	Restrict who can create NamespacedMutatingPolicy resources; audit existing ones for generator.apply() calls that target other namespaces

See all Kyverno security advisories for other Kyverno CVEs and their fixed versions.

What is CVE-2026-54523?

On July 13, 2026, a critical vulnerability was disclosed in Kyverno, the Kubernetes-native policy engine that many teams use for policy-as-code enforcement. It is tracked as CVE-2026-54523 (GHSA-79gf-7frw-68m9).

The flaw lets a tenant with permission to create a NamespacedMutatingPolicy in their own namespace bypass namespace isolation and generate resources anywhere in the cluster, kube-system included. Only releases 1.18.0 and 1.18.1 are affected. The patch shipped in 1.18.2.

The advisory rates it Critical, with a CVSS 3.1 score of 9.6 (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N). Read that vector plainly: it is exploitable over the network, attack complexity is low, and only low privileges are needed. No user interaction is required. The scope is “changed”, because the damage lands outside the component the attacker controls: a policy written in one namespace ends up acting on others.

How does the vulnerability work?

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.

That matters because creating a NamespacedMutatingPolicy is normally treated as a routine, namespace-scoped capability. A tenant who has it can call generator.apply() with any target namespace they like. Kyverno’s admission controller typically runs with cluster-wide RBAC permissions, so the generated resources get created wherever the attacker pointed them.

In practice, a low-privileged tenant could generate a RoleBinding that grants themselves cluster-admin access. They could also tamper with ConfigMaps, NetworkPolicies or Ingresses outside their own namespace. The result is a complete namespace-isolation bypass and a direct path to cluster-wide privilege escalation.

How do I fix CVE-2026-54523?

Kyverno has already released a patch:

Vulnerable: Kyverno v1.18.0, v1.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 it as a cluster-admin-adjacent permission, not a routine namespace-scoped grant.
• Audit existing NamespacedMutatingPolicy objects for matchConditions expressions that call 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.

These steps reduce exposure while you schedule the upgrade. They don’t remove the bug; only 1.18.2 or later does that.

How do Nirmata Enterprise for Kyverno (N4K) customers upgrade?

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.

Related reading

• Kyverno Runs Your Admission Control. Is It Actually Hardened? covers the configuration choices that limit the damage from bugs like this one.
• See all Kyverno security advisories.
• Nirmata Enterprise for Kyverno and Kyverno OSS.

Frequently asked questions

Which Kyverno versions are not affected by CVE-2026-54523?

The GitHub advisory lists only 1.18.0 and 1.18.1 as vulnerable, and the NVD record describes the affected range as 1.18.0 up to 1.18.2. Releases on the 1.17 line and earlier fall outside that range. If any cluster runs a 1.18 release older than 1.18.2, check the image tag the admission controller is actually running, not just the Helm chart you installed.

Where in the Kyverno code was the flaw?

According to the NVD description, the NamespacedMutatingPolicy validation in pkg/cel/policies/mpol/validate.go checked that a policy compiles but did not enforce namespace scope, and GenerateResources in pkg/cel/libs/context.go did not reject a cross-namespace target. The fix landed in Kyverno pull request 16238, with a related change in the kyverno/sdk repository, and shipped in the v1.18.2 release.

Is CVE-2026-54523 related to CVE-2026-22039?

They follow the same pattern but sit in different code. CVE-2026-22039 (CVSS 9.9) was in the apiCall feature of namespaced Policy resources, which ran API requests with the admission controller's identity; it was fixed in Kyverno 1.15.3 and 1.16.3. CVE-2026-54523 is in the NamespacedMutatingPolicy CEL generator. In both, a namespace-scoped policy author could reach outside their namespace.

When was CVE-2026-54523 disclosed?

Kyverno published the v1.18.2 release on July 10, 2026 (UTC) and the security advisory GHSA-79gf-7frw-68m9 on July 13, 2026. The CVE record was published to the National Vulnerability Database on August 26, 2026. NVD takes its 9.6 score from the GitHub advisory and, as of October 2026, shows the record's analysis status as Deferred.