CVE-2026-27211: 
CBL Mariner vulnerability analysis and mitigation

CVE-2026-27211 is a host file exfiltration vulnerability in Cloud Hypervisor, a Virtual Machine Monitor for cloud workloads, affecting versions 34.0 through 50.0. A malicious guest can overwrite its disk header with a crafted QCOW2 structure pointing to a sensitive host path, causing the hypervisor's image format auto-detection to serve host file contents to the guest upon the next VM boot or disk scan. The vulnerability was published on February 21, 2026, and patched in version 50.1 (and 51.0). It carries a CVSS v3.1 base score of 10.0 (Critical) per NVD scoring, and a CVSS v4.0 base score of 9.1 (Critical) (GitHub Advisory, Microsoft MSRC).

The root cause is classified as CWE-73 (External Control of File Name or Path): Cloud Hypervisor's QCOW2 parser reads a backing file path directly from the disk image header without validating that the path is within an expected or safe directory (GitHub Advisory). When a virtio-block device backed by a raw image is used, a guest with write access to its disk can overwrite sector 0 with a crafted QCOW2 header containing an arbitrary host filesystem path in the backing_file_path field. Upon the next VM boot or disk scan — which can be triggered by a guest-initiated reboot without management stack interaction — the auto-detection logic opens and serves the referenced host file to the guest. The critical window was widened by two commits: b3922db (January 15, 2026) enabled raw backing file support (allowing exfiltration of any host file, not just QCOW2 images), and c569a4c (February 7, 2026) removed the minimum 64KB file size constraint, enabling exfiltration of small files such as SSH keys (GitHub Advisory). Exploitation requires the backing image to be writable by the guest or sourced from an untrusted origin; deployments using only trusted, read-only images are not affected.

A malicious guest can autonomously exfiltrate arbitrary host files — including sensitive credentials such as SSH private keys, /etc/shadow, or TLS certificates — constrained only by the privileges of the Cloud Hypervisor process (GitHub Advisory). The attack does not require management stack interaction, as guest-initiated VM reboots are sufficient to trigger the disk scan. High confidentiality and integrity impacts are possible on both the vulnerable system and subsequent systems, as stolen credentials could enable lateral movement across the host infrastructure (Microsoft MSRC).

A public proof-of-concept exploit was published on GitHub on March 2, 2026, and is indexed by Sploitus (PoC GitHub). As of the time of reporting, there is no confirmed evidence of in-the-wild exploitation. The EPSS score is approximately 0.05% (0.000500000), indicating low but non-zero probability of exploitation in the near term. The vulnerability is not currently listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Qualys scanner (detection ID 917024) has added detection for this CVE (Feedly).

1. Gain guest write access: Obtain a guest VM running on a vulnerable Cloud Hypervisor instance (versions 34.0–50.0) where the backing disk image is writable by the guest (e.g., a raw image not mounted read-only).
2. Craft a malicious QCOW2 header: From within the guest, construct a QCOW2 header structure with the backing_file_offset and backing_file_size fields pointing to a sensitive host file path (e.g., /etc/shadow, /root/.ssh/id_rsa, or any file accessible to the Cloud Hypervisor process).
3. Overwrite sector 0 of the disk: Write the crafted QCOW2 header to the first sector (sector 0) of the guest's virtio-block device using direct disk I/O from within the guest (e.g., dd if=crafted_header.bin of=/dev/vda bs=512 count=1).
4. Trigger a disk scan via VM reboot: Initiate a guest-controlled reboot (e.g., reboot command inside the guest). This causes Cloud Hypervisor to re-scan the disk image without exiting the process, triggering QCOW2 auto-detection on the modified header.
5. Receive host file contents: Upon reboot, the auto-detection logic opens the host file specified in the crafted backing file path and serves its contents as the backing store for the guest disk. The guest can then read the host file's data by reading from the corresponding disk sectors (GitHub Advisory, PoC GitHub).

• File System: Unexpected or modified sector 0 on a raw disk image backing a Cloud Hypervisor VM (QCOW2 magic bytes QFI\xfb at offset 0 of a file that should be a raw image).
• Logs: Cloud Hypervisor process logs showing unexpected BackingFileOpen or BackingFileIo events referencing host filesystem paths outside of expected VM image directories; log entries indicating QCOW2 format detection on a disk previously identified as raw.
• Process: Cloud Hypervisor process opening host files (e.g., /etc/shadow, /root/.ssh/, /etc/ssl/) that are not part of the declared VM configuration, observable via strace, auditd, or eBPF-based file access monitoring.
• Network: Unusual data transfers from the guest VM to external hosts shortly after a guest-initiated reboot, potentially indicating exfiltrated credential use (GitHub Advisory).

The primary remediation is to upgrade Cloud Hypervisor to version 50.1 or 51.0, which include the core fix (backing files disabled by default via backing_files=false) and defense-in-depth hardening (explicit image typing and rejection of sector-zero writes for auto-detected raw images) (GitHub Advisory). If upgrading immediately is not possible, enable Landlock sandboxing (via the --landlock option) to restrict the Cloud Hypervisor process to only the file paths explicitly provided at startup. Additionally, run Cloud Hypervisor as an unprivileged user (never root), use containerization to isolate the process, apply strict UNIX permissions/ACLs on host files, and enforce read-only mounts for host resources passed to guests. Deployments using only trusted, read-only backing images are not affected by this vulnerability.

The vulnerability was responsibly disclosed by @DemiMarie, with deep technical analysis provided by the Crusoe Cloud Security Team (@jof), and coordinated by the Cloud Hypervisor Maintenance Team (GitHub Advisory). Social media coverage appeared on Mastodon and Bluesky via @thehackerwire shortly after the PoC was published in early March 2026. The vulnerability was also featured in a PoC weekly digest by security researcher Tony Harris (PoC Week).