Skip to content

Host File Exfiltration via QCOW Backing File Abuse

Critical
likebreath published GHSA-jmr4-g2hv-mjj6 Feb 20, 2026

Package

No package listed

Affected versions

v34.0 - v50.0

Patched versions

v51.0, v50.1

Description

Summary

Cloud Hypervisor is vulnerable to arbitrary host file exfiltration (constrained by process privileges) when using virtio-block devices backed by raw images.

A malicious guest can overwrite its disk header with a crafted QCOW2 structure pointing to a sensitive host path. Upon the next VM boot or disk scan, the image format auto-detection parses this header and serves the host file's contents to the guest. Guest-initiated VM reboots are sufficient to trigger a disk scan and do not cause the Cloud Hypervisor process to exit. Therefore, a single VM can perform this attack without needing interaction from the management stack.

Successful exploitation requires the backing image to be either writable by the guest or sourced from an untrusted origin. Deployments utilizing only trusted, read-only images are not affected.

Critical Window

While the logic existed since 2023 (081a6eb), two recent commits (neither included in released versions) significantly increased the severity:

  • b3922db (2026-01-15): Enabled raw backing file support, allowing exfiltration of any host file (not just other qcow2 files).

  • c569a4c (2026-02-07): Removed the minimum file size constraint (64KB), allowing exfiltration of small files like SSH keys or password fragments.

Affected Revisions

Revision Range Impact Notes
July 19, 2023 – Jan 15, 2026 (081a6eb to cb49595) High Host files that are valid qcow2 images can be exfiltrated (constrained by process privileges).
Jan 15 – Feb 10, 2026 (b3922db to a702bf1) Critical Arbitrary host file exfiltration supported (constrained by process privileges).
>= Feb 10, 2026 (Starting 5098322) Fixed Mitigation (backing_files=false) enabled by default.
>= Feb 19, 2026 (Starting a63315d) Hardened Added hardening measures: enables explicit image typing via the user interface and prevents sector-zero writes for autodetected raw images.

Mitigation & Workarounds

1. Upgrade to Patched Versions (Recommended)

We strongly recommend upgrading to Cloud Hypervisor v51.0 or v50.1, as these releases contain both the core fix and defense-in-depth hardening measures.

2. Enable Landlock Sandboxing

If upgrading is not possible, you should use the Landlock sandboxing capability provided by Cloud Hypervisor (e.g., via the --landlock option). Landlock restricts the Cloud Hypervisor process so it can only open file paths that were explicitly provided at startup. Even if you upgrade, using Landlock is useful defense in depth against similar vulnerabilities.

3. Restrict Process Privileges & Access

As a general best practice and immediate mitigation, ensure the host environment restricts the Cloud Hypervisor process:

  • Run as an unprivileged user (never root) to restrict file access.
  • Use containerization to isolate the process from the host filesystem.
  • Apply strict UNIX permissions/ACLs to prevent the process from reading sensitive host files.
  • Enforce read-only mounts for host resources passed to the guest when possible.

Acknowledgements

  • Reporting & Mitigation: We thank @DemiMarie for responsibly disclosing this vulnerability and for their significant engineering contributions to the fix.

  • Security Analysis: Special thanks to the Crusoe Cloud Security Team (specifically @jof) for providing deep technical analysis and validating the root cause.

  • Coordination: The security response, remediation, and disclosure process were coordinated by the Cloud Hypervisor Maintenance Team.

Severity

Critical

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v4 base metrics

Exploitability Metrics
Attack Vector Network
Attack Complexity Low
Attack Requirements Present
Privileges Required None
User interaction None
Vulnerable System Impact Metrics
Confidentiality High
Integrity None
Availability None
Subsequent System Impact Metrics
Confidentiality High
Integrity High
Availability High

CVSS v4 base metrics

Exploitability Metrics
Attack Vector: This metric reflects the context by which vulnerability exploitation is possible. This metric value (and consequently the resulting severity) will be larger the more remote (logically, and physically) an attacker can be in order to exploit the vulnerable system. The assumption is that the number of potential attackers for a vulnerability that could be exploited from across a network is larger than the number of potential attackers that could exploit a vulnerability requiring physical access to a device, and therefore warrants a greater severity.
Attack Complexity: This metric captures measurable actions that must be taken by the attacker to actively evade or circumvent existing built-in security-enhancing conditions in order to obtain a working exploit. These are conditions whose primary purpose is to increase security and/or increase exploit engineering complexity. A vulnerability exploitable without a target-specific variable has a lower complexity than a vulnerability that would require non-trivial customization. This metric is meant to capture security mechanisms utilized by the vulnerable system.
Attack Requirements: This metric captures the prerequisite deployment and execution conditions or variables of the vulnerable system that enable the attack. These differ from security-enhancing techniques/technologies (ref Attack Complexity) as the primary purpose of these conditions is not to explicitly mitigate attacks, but rather, emerge naturally as a consequence of the deployment and execution of the vulnerable system.
Privileges Required: This metric describes the level of privileges an attacker must possess prior to successfully exploiting the vulnerability. The method by which the attacker obtains privileged credentials prior to the attack (e.g., free trial accounts), is outside the scope of this metric. Generally, self-service provisioned accounts do not constitute a privilege requirement if the attacker can grant themselves privileges as part of the attack.
User interaction: This metric captures the requirement for a human user, other than the attacker, to participate in the successful compromise of the vulnerable system. This metric determines whether the vulnerability can be exploited solely at the will of the attacker, or whether a separate user (or user-initiated process) must participate in some manner.
Vulnerable System Impact Metrics
Confidentiality: This metric measures the impact to the confidentiality of the information managed by the VULNERABLE SYSTEM due to a successfully exploited vulnerability. Confidentiality refers to limiting information access and disclosure to only authorized users, as well as preventing access by, or disclosure to, unauthorized ones.
Integrity: This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information. Integrity of the VULNERABLE SYSTEM is impacted when an attacker makes unauthorized modification of system data. Integrity is also impacted when a system user can repudiate critical actions taken in the context of the system (e.g. due to insufficient logging).
Availability: This metric measures the impact to the availability of the VULNERABLE SYSTEM resulting from a successfully exploited vulnerability. While the Confidentiality and Integrity impact metrics apply to the loss of confidentiality or integrity of data (e.g., information, files) used by the system, this metric refers to the loss of availability of the impacted system itself, such as a networked service (e.g., web, database, email). Since availability refers to the accessibility of information resources, attacks that consume network bandwidth, processor cycles, or disk space all impact the availability of a system.
Subsequent System Impact Metrics
Confidentiality: This metric measures the impact to the confidentiality of the information managed by the SUBSEQUENT SYSTEM due to a successfully exploited vulnerability. Confidentiality refers to limiting information access and disclosure to only authorized users, as well as preventing access by, or disclosure to, unauthorized ones.
Integrity: This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information. Integrity of the SUBSEQUENT SYSTEM is impacted when an attacker makes unauthorized modification of system data. Integrity is also impacted when a system user can repudiate critical actions taken in the context of the system (e.g. due to insufficient logging).
Availability: This metric measures the impact to the availability of the SUBSEQUENT SYSTEM resulting from a successfully exploited vulnerability. While the Confidentiality and Integrity impact metrics apply to the loss of confidentiality or integrity of data (e.g., information, files) used by the system, this metric refers to the loss of availability of the impacted system itself, such as a networked service (e.g., web, database, email). Since availability refers to the accessibility of information resources, attacks that consume network bandwidth, processor cycles, or disk space all impact the availability of a system.
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:H/SI:H/SA:H

CVE ID

CVE-2026-27211

Weaknesses

External Control of File Name or Path

The product allows user input to control or influence paths or file names that are used in filesystem operations. Learn more on MITRE.

Credits