External risk intelligence

Kyverno NamespacedMutatingPolicy Cross-Namespace Privilege Escalation.

CVE advisorySeverity: CRITICAL (CVSS 9.4)

CVE-2026-122313

Kyverno is a Kubernetes policy engine that operates internally within a cluster. While it manages resources, it is typically deployed deep within the infrastructure stack, not directly exposed to the public internet. Accessing this vulnerability requires existing, authenticated access to the cluster, making direct internet-facing exploitation unlikely in standard deployments.

Privilege Escalation

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

External exposure likelihood

Horizon Alert

Summary of the vulnerability and why it matters

A vulnerability in Kyverno allows authenticated users with limited permissions to escalate their privileges and modify critical resources across different namespaces within a Kubernetes cluster. This could potentially lead to unauthorized access, data compromise, or service disruption. The main concern is confirming if our environment is affected and understanding the potential exposure.

Tenant policies can alter other namespaces.
Critical cluster resources could be compromised.
Confirm relevance and assess potential exposure.

Attack Path

How an attacker could exploit the issue

An attacker with existing authenticated access to a cluster can leverage a flaw in Kyverno's NamespacedMutatingPolicy to escalate privileges. By crafting a policy that targets resources in other namespaces, an attacker can manipulate critical cluster components like Roles and NetworkPolicies, potentially gaining broader control.

Requires authenticated cluster access.
Targets other namespaces via policy.
Risks broad cluster compromise.

Live Threat

Current exploitation, exposure, and threat context

A privilege escalation vulnerability in Kyverno could allow namespace-scoped tenants to modify critical cluster resources in other namespaces. This occurs when specific policy configurations bypass namespace checks, enabling attackers to target and alter resources like RoleBindings, Roles, NetworkPolicies, and ConfigMaps.

Cluster resources in other namespaces.
Unauthorized modification via policy expression.
Compromised cluster security and integrity.

Operational Fix

Recommended remediation, mitigation, and detection steps

Kyverno's privilege escalation vulnerability, enabling cross-namespace resource modification, likely falls under the responsibility of Kubernetes platform teams or the application owners utilizing Kyverno for policy enforcement. The immediate first step is to inventory all Kyverno deployments, assess their exposure within the cluster, and identify business-critical workloads they protect or manage to prioritize remediation.

Platform and application teams own this.
Verify Kyverno deployment scope and impact.
Plan and coordinate remediation actions.

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?

Kyverno is a policy engine designed for Kubernetes. It functions as a dynamic admission controller that enables administrators to manage, validate, mutate, and generate configurations for cluster resources. By using standard Kubernetes resource definitions, it helps teams enforce security and compliance best practices directly within their container orchestration environment.

What does this CVE mean for Kyverno security?

This CVE identifies a privilege escalation weakness, specifically categorized as Improper Privilege Management (CWE-269). It occurs because Kyverno fails to perform necessary namespace checks on certain policy outputs. This flaw allows a user with restricted, namespace-scoped permissions to force the cluster's background controller to modify sensitive resources in other namespaces, effectively bypassing the intended security boundaries of their own tenant environment.

How can an attacker trigger this vulnerability?

An attacker must have existing authenticated access to the cluster with the ability to define or modify policies. The trigger involves creating a specifically crafted NamespacedMutatingPolicy that directs the controller to target resources outside the attacker's assigned namespace. If the policy configuration lacks valid constraints, the system will process the unauthorized mutation. Simply having Kyverno installed does not trigger the bug; it requires active, malicious policy input.

Do I need to worry about this if my cluster is internal?

While internal clusters are safer, Halo Surface Signal notes that Kyverno typically operates deep within the infrastructure stack, making direct public exposure unlikely. However, because this vulnerability requires authenticated access, it poses a significant threat if a malicious actor or compromised account gains a foothold within your cluster. You should evaluate the risk based on your internal access controls and the level of trust placed in users who can create policies.

When should I take action to remediate this?

You should begin by performing an inventory of all Kyverno deployments to verify if you are running version 1.17.0 through 1.19.1. Once identified, coordinate with your platform or security teams to prioritize upgrading to a patched version. Assessing which namespaces and critical workloads are managed by Kyverno will help you determine the urgency and potential impact of these changes on your production services.

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.