Cloud Hypervisor – Host File Exfiltration from Guest VM via QCOW Backing File Abuse
CVE ID: CVE-2026-27211
Product: Cloud Hypervisor
Vulnerability Type: Arbitrary Host File Read / Data Exfiltration
CWE: CWE-73 – External Control of File Name or Path
CVSS (v4.0): 9.1 (Critical)
Severity: Critical
Attack Vector: Network (guest-to-host boundary)
Privileges Required: None (from attacker perspective inside guest)
User Interaction: None
Exploitability: High in multi-tenant or untrusted guest environments
Exploit Availability: No public weaponized exploit observed at the time of disclosure; exploitation is technically straightforward
Fixed Versions: v50.1 and v51.0
Affected Versions: v34.0 through v50.0
Official Patch / Upgrade Link:
https://github.com/cloud-hypervisor/cloud-hypervisor/releases
Executive Summary
A critical vulnerability was identified in Cloud Hypervisor that allows a malicious guest virtual machine to read arbitrary files from the host system. The issue arises from improper handling of QCOW2 backing files combined with automatic image format detection.
Under specific conditions, a crafted disk image header can manipulate the hypervisor into opening and reading sensitive files from the host filesystem. The contents of those files can then be exposed to the guest VM through the virtual block device interface.
Impact is limited only by the file permissions of the Cloud Hypervisor process. If the hypervisor runs with elevated privileges, highly sensitive host data such as SSH private keys, configuration files, or credential material may be exposed.
Technical Root Cause
Cloud Hypervisor supports QCOW2 disk images with backing files. A QCOW2 image may reference another image file as its base layer.
The vulnerability stems from the following conditions:
- Automatic image format detection was performed.
- Backing file references were followed automatically.
- Backing file paths were not sufficiently restricted.
- Raw backing files were supported in recent changes.
- A previous minimum file size validation was removed.
If a guest VM controls or can modify the disk image header, it can overwrite the QCOW2 header and inject a malicious backing file path pointing to any file accessible by the hypervisor process on the host.
When the VM reboots or when the disk is scanned, the hypervisor attempts to resolve the backing file. The referenced host file is opened and read. The data is then exposed through the virtual disk interface and becomes accessible inside the guest.
This behavior effectively breaks the VM-to-host isolation boundary.
Attack Scenario
The exploitation flow typically occurs as follows:
- An attacker gains control of a guest VM.
- The attacker modifies the writable disk image or backing image header.
- A malicious QCOW2 header is crafted referencing a sensitive host file (example:
/root/.ssh/id_rsa). - The guest triggers a reboot or disk reinitialization.
- Cloud Hypervisor auto-detects the disk format and follows the injected backing file path.
- The hypervisor reads the host file.
- The contents are returned through the virtual block device to the guest.
- The attacker extracts the file from inside the VM.
No host-level authentication bypass is required. The vulnerability relies entirely on image metadata manipulation.
Impact
The following host data may be exposed:
- SSH private keys
/etc/shadow- TLS private keys
- Cloud API credentials
- Container runtime secrets
- Configuration files
- Internal tokens stored in readable paths
If the hypervisor runs as root, the blast radius is significant.
In multi-tenant cloud deployments, this becomes a cross-boundary data exposure risk.
Exploitability Assessment
Exploitation requires:
- Control over a guest VM
- Ability to modify the disk image header
- Writable or attacker-controlled backing image
- Hypervisor version between v34.0 and v50.0
No complex memory corruption or ROP chains are required. The attack is logic-based and reliable.
Although no public exploit kit is known, proof-of-concept reproduction for educational purposes is straightforward in lab conditions.
Proof-of-Concept Overview
For educational testing in an isolated lab:
- Create a QCOW2 image.
- Manually edit the header to inject a malicious backing file path.
- Ensure the guest has write access to the image.
- Trigger a reboot.
- Inside the guest, read sectors from the virtual disk.
- Extract recovered host file content.
Detection Strategy
Detection must focus on host-level telemetry rather than guest logs.
The following indicators are strong signals:
- Cloud Hypervisor process opening unexpected sensitive files.
- Reads to
/root,/etc/ssh,/etc/shadow,/var/lib, or secret directories. - Correlation between VM reboot events and host file access.
- Unusual disk header modifications.
- QCOW2 backing path referencing absolute host paths.
Log Sources
- auditd (Linux host)
- Sysmon for Linux
- eBPF file monitoring
- Cloud Hypervisor verbose logs
- Host OS security logs
- Container runtime logs (if hypervisor runs in container)
Detection Rules and Queries
Auditd Rule (Host-Based Monitoring)
-a always,exit -F arch=b64 -S open,openat,read \
-F exe=/usr/bin/cloud-hypervisor \
-F dir=/root/ \
-k ch_sensitive_access
-a always,exit -F arch=b64 -S open,openat,read \
-F exe=/usr/bin/cloud-hypervisor \
-F path=/etc/shadow \
-k ch_shadow_access
Splunk Query
index=linux_audit exe="/usr/bin/cloud-hypervisor"
(path="/root/*" OR path="/etc/shadow" OR path="/etc/ssh/*")
| table _time host exe path syscall success
Elastic (KQL)
process.name: "cloud-hypervisor" AND
file.path: (/root/* OR /etc/shadow OR /etc/ssh/*)
Correlation Query (Reboot + File Access)
(process.name:"cloud-hypervisor" AND file.path:/root/*)
AND
(event.category:process AND process.command_line:*reboot*)
eBPF-Based Monitoring Idea
Alert when:
- Process = cloud-hypervisor
- Syscall = open/openat
- File path not under approved image directory
- Access mode = read
Indicators of Compromise
- Cloud Hypervisor reading sensitive files unrelated to VM disk storage.
- Backing file metadata referencing absolute host paths.
- Small host files accessed immediately after VM reboot.
- Unexpected disk header modifications.
- Guest VM retrieving data resembling host file contents.
Forensic Guidance
If compromise is suspected:
- Collect audit logs.
- Identify all file access events by cloud-hypervisor.
- Dump VM disk headers for analysis.
- Inspect QCOW2 metadata.
- Validate hypervisor process UID and permissions.
- Review VM reboot timeline.
Mitigation
Immediate mitigation steps include:
- Upgrade to v50.1 or v51.0.
- Disable backing file support if not required.
- Enforce explicit image type configuration.
- Run Cloud Hypervisor as non-root.
- Apply filesystem sandboxing (Landlock).
- Restrict hypervisor access to only required directories.
- Ensure backing images are read-only and trusted.
Hardening Recommendations
- Use mandatory access control (SELinux or AppArmor).
- Isolate hypervisor process in a container.
- Limit host filesystem mount exposure.
- Separate hypervisor user from system administration.
- Monitor disk image integrity via hashing.
Risk Rating for Environments
| Environment Type | Risk Level |
|---|---|
| Multi-tenant cloud | Critical |
| CI/CD ephemeral VM runners | High |
| Single-tenant lab | Moderate |
| Hardened least-privilege deployment | Reduced but not eliminated |
Remediation
Upgrade immediately to:
- Cloud Hypervisor v50.1
- Cloud Hypervisor v51.0
Official release link:
https://github.com/cloud-hypervisor/cloud-hypervisor/releases
No workaround fully eliminates risk without patching.
Conclusion
CVE-2026-27211 represents a boundary failure between guest and host isolation. The issue does not rely on memory corruption or kernel escape techniques. It is a design-level file resolution flaw that can be exploited reliably when conditions permit.
Because exploitation requires only disk metadata manipulation and a reboot trigger, environments running untrusted guests are especially exposed.
Immediate upgrade and host-level monitoring are strongly advised.
