dbcve.org
Link Following (Symlink)Weakness · CWE-59

CVE-2026-7374

CRITICAL · 9.9 CVSS v3.1 Published 2026-05-26
Mitigation only
No fix yet — a mitigation exists. There is no fixed release. A documented workaround reduces exposure in the meantime.
See remediation →
100/100
Remediation priority · Urgent
Remotely reachable Zero-click

Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.

NVD · unedited
A flaw was found in KubeVirt's virt-handler component. This vulnerability allows an authenticated OpenShift user with edit permissions in a single namespace to exploit improper symlink validation when connecting to virtual machine console sockets. By replacing the console socket with a symlink to the host's container runtime (CRI-O) socket, an attacker can hijack virt-handler's privileged connection. This enables the attacker to access any Unix socket on the host, potentially leading to full control of the node and the entire cluster.

Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.

dbcve analysis · moderate confidence

KubeVirt's virt-handler has improper symlink validation when handling VM console socket connections. An authenticated user with namespace-level edit permissions can replace a console socket with a symlink pointing to the host's CRI-O socket, hijacking virt-handler's privileged connection and gaining access to any Unix socket on the host node.

MitigationImplement strict symlink validation in virt-handler to verify socket targets are within expected paths and reject symlinks to sockets outside the VM's designated namespace. Additionally, restrict socket file permissions and add runtime verification of socket integrity before connection.

Verify against the referenced sources before acting — the references below are authoritative for this CVE, this summary is not.

CVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.

From the vector
Attack vector
Network
Complexity
Low
Privileges
Low
User interaction
None
Scope
Changed
Confidentiality
High
Integrity
High
Availability
High

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H

Am I affected? How to checkSteps we derive from the advisory and the affected-version data, so you can decide whether this CVE reaches your setup. They are a guide, not a scan — your own configuration is the authority.

dbcve checks

Work through these to decide whether this CVE applies to you.

  1. Verify KubeVirt installation and version
    Run 'kubectl get kubevirt -A' to list KubeVirt installations, then check the operator version with 'kubectl get kubevirt -A -o yaml' or check the virt-handler deployment version with 'kubectl get deployment -n kubevirt -l app=virt-handler'
    Affected if KubeVirt is installed and the version cannot be confirmed as patched against CVE-2026-7374
  2. Identify console socket paths in the cluster
    Check for VM console socket files in the virt-handler pods: 'kubectl exec -n kubevirt <virt-handler-pod> -- ls -la /var/run/kubevirt-console/' and review the virt-launcher pods for socket files in the namespace where VMs are created
    Affected if Console sockets exist in locations writable by namespace-level users without proper symlink validation in place
  3. Review RBAC permissions for console socket access
    Run 'kubectl auth can-i create pod -n <target-namespace>' and check if users with edit permissions can modify pod specs or access the host filesystem; review ClusterRoleBindings related to virtual machine resources with 'kubectl get clusterrole -o yaml | grep -A 10 virt'
    Affected if Users with namespace-level edit permissions can manipulate pod resources or access host sockets
  4. Check pod security policies or admission controls
    Review PodSecurityPolicy, Kyverno policies, or OPA Gatekeeper policies that govern pod creation in namespaces where VMs exist; check for restrictions on hostPath mounts and socket access with 'kubectl get psp -A' or relevant policy exports
    Affected if No restrictive pod security policies exist to block socket file access or hostPath mounts
  5. Verify symlink validation is implemented
    Review virt-handler configuration for symlink validation settings; check the virt-handler container logs for any symlink-related validation messages using 'kubectl logs -n kubevirt -l app=virt-handler'
    Affected if No symlink validation is enforced in the virt-handler configuration or logs show missing validation

A user is affected if KubeVirt with virt-handler is running without confirmed patched version and namespace users with edit permissions can access or manipulate console sockets.

Generated from the published advisory. Verify against your own configuration.

Check your environment

Paste your version and any relevant configuration and it will be compared against the affected criteria above. Do not include secrets or credentials.

AI-assisted, checked against the advisory. Informational, not a guarantee.

Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.

From vendor data
Mitigation available No clean upgrade yet — mitigate in the meantime
Mitigation

Implement strict symlink validation in virt-handler to verify socket targets are within expected paths and reject symlinks to sockets outside the VM's designated namespace. Additionally, restrict socket file permissions and add runtime verification of socket integrity before connection.

Have this fixed Scoped from the published advisory
  • Consultation8.0 h
  • Implementation16.0 h
  • Testing12.0 h
  • Review / QA6.0 h
42.0 hours of engineering $7,360
Get help mitigating

An estimate, not a bill — we confirm scope with you before any work starts. Need it this week? Rush from $11,776.

Scan for this in your stack

Free · runs locally
dbcve dependency scanner

Check whether your project pulls in CVE-2026-7374 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.

Get it on GitHub Scan in the browser

References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.

Primary sources

Practitioner notes

Contributed

Peer-ranked notes from engineers who’ve handled CVE-2026-7374 in production — separate from our analysis above.

No notes yet

Be the first to add a field note for this CVE — a mitigation you’ve verified, a version caveat, or a link to a working fix. Sign in above to contribute.

What this is

A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.

What belongs here
  • Verified mitigations, workarounds, and config changes
  • Version or environment caveats, and links to real fixes
  • No weaponised exploit code, or anything meant to cause harm
  • No spam, self-promotion, credentials, or personal data