External risk intelligence

Kyverno Privilege Escalation via Generate Rule Permission Check.

CVE advisorySeverity: CRITICAL (CVSS 9.3)

CVE-2026-122302

The vulnerability exists within Kyverno, a Kubernetes policy engine that operates as an internal cluster controller. It requires the attacker to already have namespace admin privileges within the Kubernetes cluster to exploit. It is not an internet-facing service, API gateway, or edge component, but rather an internal administrative tool managed within private infrastructure.

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 security issue has been identified in Kyverno, a tool for managing Kubernetes policies. This vulnerability could allow users with administrative access within a specific namespace to create resources outside of their authorized scope, potentially impacting cluster-wide resources. The primary concern is to determine if our environment uses this technology and is exposed.

Unauthorized users may create unintended cluster resources.
It could allow namespace admins to bypass intended controls.
Confirm relevance and potential exposure within our environment.

Attack Path

How an attacker could exploit the issue

An attacker with administrative access within a specific Kubernetes namespace can escalate their privileges. This is achieved by creating a policy with "generate rules" that target resources in other namespaces or cluster-wide. The vulnerability lies in the admission control's failure to properly check the user's permissions, instead verifying the controller's. This allows the controller to create or duplicate resources across the entire cluster, bypassing intended access restrictions.

Requires namespace admin privileges.
Triggers via namespaced policy with generate rules.
Grants broad cluster-wide resource creation.

Live Threat

Current exploitation, exposure, and threat context

This vulnerability could allow a namespace administrator to create or modify resources in other namespaces or at the cluster level, bypassing intended access restrictions when Kyverno's generate-rule admission checks are configured to permit it.

Cluster resources and namespaces.
Namespace admin creates a policy.
Unauthorized resource creation.

Operational Fix

Recommended remediation, mitigation, and detection steps

Namespace administrators are the primary actors responsible for addressing this privilege escalation vulnerability within Kyverno. The initial step involves identifying all instances of Kyverno, determining their reachability and criticality, and then confirming the accountable owner for remediation. Planning the fix should be based on the assessed risk.

Identify Kyverno deployments and owners.
Verify affected namespaces and policies.
Plan remediation based on risk assessment.

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 is it used in Kubernetes?

Kyverno is a policy engine designed specifically for Kubernetes. It functions as an admission controller that validates, mutates, and generates configurations to enforce security and operational best practices. Platform teams use it to automate governance across a cluster, ensuring that resource deployments consistently follow defined organizational standards.

What does CVE-2026-122302 mean by privilege escalation?

This vulnerability falls under the weakness class of Improper Privilege Management (CWE-269). It means that a user with restricted, namespace-level administrative permissions can perform actions they are not supposed to, such as creating or modifying resources in other namespaces or across the entire cluster, effectively elevating their authority beyond their intended scope.

How does an attacker trigger this vulnerability?

An attacker triggers the bug by creating a namespaced policy containing 'generate rules' designed to target resources outside their current administrative boundaries. The system incorrectly validates the request against the high-level permissions of the Kyverno controller itself rather than the restricted permissions of the user who submitted the policy. Simple resource creation or standard operations that do not involve these specific generate rules do not trigger the issue.

Is this vulnerability exposed to the internet?

According to Halo Surface Signal, this is considered an internal administrative issue. Since Kyverno operates as a controller inside your private Kubernetes cluster, it is not an internet-facing service or edge component. An attacker must already possess administrative control over a specific namespace within your cluster to attempt an exploit.

What should I do if my team runs Kyverno?

Begin by auditing your current Kyverno deployments to determine if you are using affected versions. Locate the owners responsible for your Kubernetes clusters and verify if any existing generate-rule policies could be misused by namespace administrators. Prioritize planning for an update to the patched version, ensuring that your remediation schedule aligns with your internal risk assessment for cluster governance.

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.