External risk intelligence

Kyverno Cross-Namespace Resource Creation Vulnerability

CVE advisorySeverity: CRITICAL (CVSS 9.6)

CVE-2026-54523

Kyverno is a Kubernetes-native policy engine that operates as an internal cluster admission controller. It is not an internet-facing service, API, or gateway. The vulnerability requires authenticated access to create specific policy objects within the cluster, making it an internal-only component and not a reachable public network surface.

Privilege Escalation

Halo Surface Signal: 1 out of 5 — much less likely to be public-facing.

External exposure likelihood

Horizon Alert

Summary of the vulnerability and why it matters

A policy engine used in cloud-native platforms has a vulnerability that allows authenticated users to create or modify resources in unintended namespaces, potentially leading to unauthorized changes and privilege escalation. This issue affects specific versions of Kyverno.

Policy engine allows unauthorized resource changes.
Affects cloud platforms; requires internal access.
Confirm relevance and assess exposure internally.

Attack Path

How an attacker could exploit the issue

An attacker with the ability to create specific policy objects in one namespace could leverage a vulnerability in Kyverno's policy compiler. This would allow them to bypass namespace restrictions and instruct the admission controller, which has broad permissions, to create or modify resources in other namespaces. This could lead to unauthorized changes and a rise in privileges within the cluster.

Authenticated access required.
Invoking cross-namespace resource creation.
Unauthorized resource modification and privilege escalation.

Live Threat

Current exploitation, exposure, and threat context

When supported by the advisory, a user who can create specific policy objects in one namespace could cause the admission controller to create or modify resources like ConfigMaps, Secrets, and RoleBindings in other namespaces. This could lead to unauthorized changes to cluster configuration.

Cluster-wide resources and configuration.
Creating policies in one namespace.
Unauthorized resource modification.

Operational Fix

Recommended remediation, mitigation, and detection steps

Cloud-native platform engineering teams using Kyverno are responsible for addressing this vulnerability. The initial step involves identifying all instances of Kyverno within your environment, confirming their reachability and business criticality, and then identifying the accountable owner before planning remediation based on the assessed risk.

Platform and Security teams own the issue.
Verify Kyverno deployment and policy configurations.
Plan remediation during the next maintenance window.

Supplementary metadata

CVSS vector

Validate whether this threat affects your internet-facing exposure.

Halo Threat Intelligence helps prioritize remediation with Halo Surface Signal and H/A/L/O context. Start exposure validation with a free external attack surface trial.

Free EASM Trial See How Signal Works

Frequently asked questions

What is Kyverno and why do platform teams use it?

Kyverno is a policy engine designed specifically for Kubernetes. It functions as an admission controller, allowing platform engineering teams to manage, validate, mutate, and generate configurations for cluster resources. By enforcing guardrails automatically, it helps teams maintain compliance and security standards across their cloud-native environments.

What does CWE-862 mean for this CVE-2026-54523 vulnerability?

CWE-862 represents Missing Authorization. In this context, it means the software fails to properly verify if a user has the right to perform a specific action across different sections of the system. CVE-2026-54523 occurs because the policy compiler does not restrict where resources can be generated, allowing a policy scoped to one namespace to inappropriately affect others.

How does an attacker trigger this resource creation flaw?

An attacker must have permission to create NamespacedMutatingPolicy objects within a single namespace. If they possess this access, they can craft a policy that invokes the generator library to target a different, unauthorized namespace. Simply having read access or observing policies does not trigger the bug; the attacker must be able to define or modify these specific policy objects.

Is my cluster at risk if it isn't internet-facing?

According to Halo Surface Signal, this vulnerability is considered an internal cluster issue. Because Kyverno operates as an admission controller rather than an internet-facing gateway, it is not directly reachable from the public web. However, you should still evaluate the risk based on your internal user permissions, as the vulnerability requires authenticated access to create policies.

What should I do if I am running an affected version of Kyverno?

First, identify all instances of Kyverno in your environment to determine if they are running version 1.18.0 or 1.18.1. Locate the responsible platform or security team for these deployments. Once confirmed, prioritize upgrading to version 1.18.2 or later, as this release contains the necessary logic to enforce correct namespace scoping and prevent unauthorized cross-namespace actions.

References

Written by Nicholas Merritt

Nicholas Merritt is VP of Security Solutions at Halo Security. With more than 25 years across application security, vulnerability prioritization, and offensive security, he helps teams translate threat data into practical exposure validation and remediation focus. He authors Halo Threat Intelligence CVE advisories using Halo Surface Signal and H/A/L/O context to prioritize internet-facing risk.