CVE-2026-27211: Cloud Hypervisor Information Disclosure

CVE-2026-27211 Overview

CVE-2026-27211 is an External Control of File Name or Path vulnerability (CWE-73) affecting Cloud Hypervisor, a Virtual Machine Monitor designed for cloud workloads. This vulnerability allows a malicious guest VM to exfiltrate arbitrary host files by manipulating virtio-block disk headers when using raw image backing files.

The flaw exists in versions 34.0 through 50.0 and enables guest-initiated attacks that can read sensitive host files constrained only by the Cloud Hypervisor process privileges. The attack leverages the automatic image format detection mechanism, which parses crafted QCOW2 headers pointing to arbitrary host paths during VM boot or disk scan operations.

Critical Impact

A malicious guest VM can exfiltrate sensitive host files including configuration files, credentials, and secrets without requiring any interaction from the host management stack. Guest-initiated reboots are sufficient to trigger exploitation.

Affected Products

• Cloud Hypervisor versions 34.0 through 50.0
• Deployments using virtio-block devices backed by raw images
• Configurations where backing images are writable by the guest or sourced from untrusted origins

Discovery Timeline

• 2026-02-21 - CVE CVE-2026-27211 published to NVD
• 2026-02-24 - Last updated in NVD database

Technical Details for CVE-2026-27211

Vulnerability Analysis

This vulnerability exploits a fundamental weakness in how Cloud Hypervisor handles disk image format auto-detection for virtio-block devices. When a VM uses a raw disk image, the hypervisor's image parser examines the disk header on boot to determine the image format. A malicious guest can overwrite sector 0 of its disk with a carefully crafted QCOW2 header structure that specifies a backing file path pointing to a sensitive host file.

Upon the next VM boot or disk scan operation, the auto-detection logic interprets the manipulated header as a valid QCOW2 image with a backing file. The hypervisor then opens and reads the specified host file, serving its contents to the guest as disk data. This attack is particularly dangerous because guest-initiated VM reboots do not cause the Cloud Hypervisor process to exit, allowing a single compromised VM to repeatedly exploit the vulnerability without host intervention.

Root Cause

The root cause is insufficient validation and access control in the QCOW2 backing file handling mechanism. The image format detection code did not properly restrict backing file paths or validate that backing file references were legitimate. Additionally, the lack of controls on sector 0 write operations allowed guests to corrupt disk metadata with malicious headers.

Attack Vector

The attack is network-accessible as it can be triggered by any guest VM with write access to its backing disk image. The attacker overwrites the disk header with a crafted QCOW2 structure containing a backing_file field pointing to a target host path such as /etc/shadow, /etc/passwd, or cloud credential files. When the VM reboots (which the guest can initiate), the hypervisor parses the header and follows the backing file reference, exposing host file contents to the guest.

// Security patch - Adding backing file control option
// Source: https://github.com/cloud-hypervisor/cloud-hypervisor/commit/509832298b6865365b00bda88722e76e41ce7f41

impl QcowDiskSync {
    pub fn new(file: File, direct_io: bool, backing_files: bool) -> QcowResult<Self> {
        if backing_files {
            Ok(QcowDiskSync {
                qcow_file: Arc::new(Mutex::new(QcowFile::from(RawFile::new(file, direct_io))?)),
            })
        } else {
            Ok(QcowDiskSync {
                qcow_file: Arc::new(Mutex::new(QcowFile::from_with_nesting_depth(
                    RawFile::new(file, direct_io),
                    0,
                )?)),
            })
        }
    }
}

Source: GitHub Commit 509832298b

The fix introduces a backing_files parameter that controls whether QCOW2 backing file references are honored. When disabled, the nesting depth is set to 0, preventing the hypervisor from following backing file chains.

Detection Methods for CVE-2026-27211

Indicators of Compromise

• Unexpected file access attempts from the Cloud Hypervisor process to sensitive host paths
• QCOW2 headers detected at the beginning of raw disk images
• Guest VMs repeatedly rebooting without apparent cause
• Anomalous read patterns on host files not associated with VM disk images

Detection Strategies

• Monitor Cloud Hypervisor process file access using auditd or eBPF-based tools for suspicious path traversal
• Implement file integrity monitoring on VM disk images to detect sector 0 modifications
• Analyze disk image headers before VM startup to detect embedded backing file references
• Deploy runtime security monitoring to alert on unexpected file reads by hypervisor processes

Monitoring Recommendations

• Enable comprehensive logging for Cloud Hypervisor disk operations
• Configure alerts for file access outside expected VM storage directories
• Monitor guest reboot frequency as anomalous patterns may indicate exploitation attempts
• Implement network segmentation to limit the blast radius of compromised VMs

How to Mitigate CVE-2026-27211

Immediate Actions Required

• Upgrade Cloud Hypervisor to version 50.1 or later immediately
• Enable Landlock sandboxing to restrict hypervisor file system access
• Audit all VM disk configurations for writable raw images from untrusted sources
• Restrict Cloud Hypervisor process privileges using seccomp or AppArmor profiles

Patch Information

Cloud Hypervisor has addressed this vulnerability in version 50.1. The fix includes multiple security enhancements:

1. Backing file control option - New configuration to disable backing file references in QCOW2 parsing (Commit 509832298b)
2. Sector 0 write protection - Rejects discard and write-zeroes requests targeting sector 0 (Commit a63315df54)
3. Direct I/O tracking - Improved backing file handling with direct I/O awareness (Commit 081a6ebb51)

For complete details, refer to the GitHub Security Advisory GHSA-jmr4-g2hv-mjj6.

Workarounds

• Use only trusted, read-only disk images for VMs where possible
• Enable Landlock sandboxing to constrain hypervisor file system access
• Configure AppArmor or SELinux policies to restrict Cloud Hypervisor to only required paths
• Avoid using raw image formats for untrusted workloads; prefer pre-validated QCOW2 images

# Configuration example - Restricting Cloud Hypervisor with AppArmor
# Create /etc/apparmor.d/cloud-hypervisor profile

profile cloud-hypervisor /usr/bin/cloud-hypervisor {
  # Allow read access to VM images directory only
  /var/lib/cloud-hypervisor/images/** r,
  
  # Deny access to sensitive host paths
  deny /etc/shadow r,
  deny /etc/passwd r,
  deny /root/** r,
  deny /home/** r,
  
  # Allow necessary system access
  /dev/kvm rw,
  /dev/vhost-net rw,
}