External risk intelligence

Kyverno Authorization Bypass Vulnerability Allows Privilege Escalation

CVE advisorySeverity: CRITICAL (CVSS 9.4)

CVE-2026-124440

Kyverno is a Kubernetes admission controller that operates internally within a cluster. It is not an internet-facing service, edge gateway, or public API endpoint. Its function is to manage and enforce policies on internal Kubernetes API requests, making it a backend component that is not directly reachable from the public internet in normal deployments.

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

This advisory concerns a critical vulnerability in Kyverno, a tool used for managing Kubernetes policies. The issue allows unauthorized users to bypass security controls, potentially leading to elevated privileges within the cluster. This could enable attackers to access sensitive information or manipulate cluster resources.

Bypass allows tenants to make unauthorized requests.
Could lead to cluster administration takeover.
Confirm relevance and assess potential exposure.

Attack Path

How an attacker could exploit the issue

An attacker with limited permissions within a Kubernetes cluster can exploit a vulnerability in Kyverno's API call namespace clamp. By crafting a special URL, the attacker can trick the admission controller into executing cross-namespace and cluster-scoped API requests. This allows them to escalate their privileges to that of a cluster administrator, enabling them to read sensitive data and modify cluster configurations.

Requires authenticated cluster access.
Malformed URL bypasses namespace restrictions.
Cluster-wide privilege escalation.

Live Threat

Current exploitation, exposure, and threat context

This vulnerability could allow a tenant with namespace-level access to bypass authorization controls within Kyverno. By sending specially crafted requests, an attacker could exploit this to issue commands that affect resources outside their own namespace, including potentially gaining cluster-admin privileges. This means sensitive Kubernetes resources and configurations across the entire cluster could be at risk.

Cluster-scoped resources and configurations.
Exploiting malformed API requests.
Escalation to cluster administrator privileges.

Operational Fix

Recommended remediation, mitigation, and detection steps

The Kyverno authorization bypass vulnerability impacts cluster administrators and platform teams responsible for Kubernetes security. The first practical move is to identify Kyverno deployments, confirm their reachability and criticality, and then plan remediation with the platform or application owner.

Platform or application owners should own.
Verify Kyverno deployment reachability.
Plan remediation with vendor coordination.

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 Kubernetes clusters use it?

Kyverno is an open-source policy engine designed for Kubernetes. It functions as an admission controller, which means it intercepts requests sent to the Kubernetes API to validate, mutate, or generate resources. Teams use it to enforce security standards, ensure compliance, and automate operational tasks, such as preventing insecure container configurations or requiring specific labels on resources across a cluster.

What does the CVE-2026-124440 vulnerability actually do?

This vulnerability is an authorization bypass, categorized as CWE-441: Unintentional Proxy/Intermediary. It occurs because Kyverno fails to properly clamp or restrict the namespace for API calls initiated by policies. By appending malformed percent-escapes to a URL path, an attacker can trick the system into bypassing its own security checks, allowing unauthorized cross-namespace or cluster-wide actions.

How is this Kyverno vulnerability triggered?

An attacker needs existing, authenticated access to the Kubernetes cluster to trigger this issue. They must be able to create or manipulate namespaced Policies. The bug is specifically triggered when these policies use the apiCall feature with malformed URL inputs. Simply having access to the cluster is not enough; the attacker must be able to influence the specific policy definitions that Kyverno evaluates.

Is my cluster at risk if it is not exposed to the internet?

According to Halo Surface Signal, Kyverno is an internal component that manages cluster-level policies and is not typically exposed to the public internet. However, this does not mean the risk is zero. The vulnerability allows a user who already has limited, legitimate access to a single namespace to escalate their privileges and potentially take over the entire cluster, making this a significant internal threat.

What should I do if I am running Kyverno 1.19.1?

Start by identifying all Kyverno instances currently deployed in your environments. Verify your version to confirm if you are on 1.19.1, as the issue is resolved in 1.19.2. Coordinate with your platform or security teams to schedule an upgrade to a secure version. While planning the update, you may want to audit current policy definitions to see if any use the vulnerable apiCall feature.

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.