External risk intelligence

KubeVirt virt-handler Symlink Validation Flaw Allows Node and Cluster Compromise.

CVE advisorySeverity: CRITICAL (CVSS 9.9)

CVE-2026-7374

The vulnerability requires the attacker to already have authenticated access to the system as a user with specific edit permissions within a namespace. It involves manipulation of internal virtual machine console sockets and host-level Unix sockets, which are not exposed to the public internet.

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 vulnerability in KubeVirt's virt-handler component could allow an authenticated user to hijack privileged connections, potentially leading to full control of the host node and the entire cluster. This stems from improper validation of symlinks when connecting to virtual machine console sockets.

Flaw allows authenticated user to hijack connections.
High-impact risk to node and cluster control.
Confirm relevance and exposure within your environment.

Attack Path

How an attacker could exploit the issue

An attacker with edit permissions in a specific namespace could hijack a privileged connection to a virtual machine's console. This is achieved by exploiting a flaw in how symlinks are handled when connecting to console sockets. By manipulating these symlinks, the attacker can gain access to other Unix sockets on the host, potentially leading to complete control over the node and the cluster.

Authenticated user with edit permissions.
Replacing console socket with a symlink.
Full control of node and cluster.

Live Threat

Current exploitation, exposure, and threat context

This vulnerability could allow an authenticated user with edit permissions in a single namespace to gain access to any Unix socket on the host. This could lead to full control over the node and potentially the entire cluster.

Host node and cluster control.
Hijacking privileged console connections.
Full compromise of the Kubernetes node.

Operational Fix

Recommended remediation, mitigation, and detection steps

This critical vulnerability in KubeVirt's virt-handler component impacts systems running OpenShift. Responsibility likely falls to platform or infrastructure teams managing OpenShift and its virtual machine workloads, in coordination with the security team for exposure assessment. The first step is to identify all instances of the affected component, confirm reachability and business criticality, and then engage the accountable owner to plan a risk-based remediation strategy.

Platform/infrastructure teams own the issue.
Verify affected component reachability.
Plan remediation based on risk.

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 KubeVirt and the virt-handler component?

KubeVirt is a Kubernetes add-on that enables teams to run virtual machines alongside standard containers. It uses virt-handler, a specialized component that acts as the bridge between the Kubernetes node and the virtual machine's lifecycle. It specifically manages operations like console connections, ensuring that authorized users can interact with virtual machines directly through the infrastructure layer.

How does CVE-2026-7374 work?

This flaw is a type of 'Improper Link Following,' classified as CWE-59. It occurs because virt-handler does not properly verify symbolic links when establishing a console connection. An attacker can replace a legitimate console socket file with a symlink pointing to sensitive areas on the host, such as the container runtime socket. This tricks the privileged virt-handler process into connecting to the wrong destination, granting the attacker unauthorized access to system-level controls.

Do I need special access to trigger this vulnerability?

Yes. This bug cannot be triggered by an unauthenticated remote attacker. It requires an attacker to already possess an authenticated account on the OpenShift platform with edit permissions within a specific namespace. Simply attempting to connect to a virtual machine console or interacting with public-facing web applications will not trigger this vulnerability.

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

Halo Surface Signal indicates this vulnerability is very unlikely to be reachable from the public internet. Because the attack requires local namespace permissions and direct manipulation of internal Unix sockets on the host, the risk is primarily internal. However, if your environment allows untrusted users to hold edit permissions, your internal risk profile remains high.

When should I prioritize fixing this vulnerability?

You should prioritize remediation if your team manages OpenShift environments where virtual machines are deployed. The first step is to confirm where KubeVirt is running in your infrastructure. Engage your platform or infrastructure teams to identify these assets, verify which users hold edit permissions in your namespaces, and prepare to apply security updates provided by your vendor.

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.