CVE-2026-24708

Think of Nova as the system that manages virtual machine disks. In affected setups, if someone can provide a “fake” disk image header and then make Nova resize the disk, Nova may run the disk conversion tool in a way that performs an unsafe operation, potentially wiping or damaging the host’s data related to that disk.

This matters if you run OpenStack Nova as part of your infrastructure, especially on compute nodes that use the Flat image backend (commonly configured with use_cow_images=False). The issue is tied to resizing root or ephemeral disks using that backend, not all OpenStack Nova usage.

It’s a risk only when the vulnerable image-backend path is reachable in your environment—typically on compute nodes that actually use the Flat image backend and where an attacker can influence the disk image used for a resize operation.

This is AMBER because the flaw can cause destructive unsafe image resize behavior on the host side, which is the kind of issue that can lead to serious downtime and data loss. However, there is no KEV listing and no public exploit code on record, so it’s not known to be broadly exploited right now.

Focus on patching promptly if your OpenStack Nova compute nodes use the Flat image backend, and prioritize upgrades based on your branch (30/31/32).

1. Confirm exposure in your environment

   • Identify your running OpenStack Nova version and branch.
   • Determine whether your affected compute nodes use the Flat image backend. The vulnerability description notes that compute nodes using the Flat image backend (usually configured with use_cow_images=False) are the ones at risk.
   • Look for whether you perform disk resize operations (especially involving root or ephemeral disks) as part of normal operations or tenant workflows.

2. Map to fixed versions and plan the upgrade

   • If you are on the 30.x branch, upgrade to at least 30.2.2.
   • If you are on the 31.x branch, upgrade to at least 31.2.1.
   • If you are on the 32.x branch, upgrade to at least 32.1.1.

3. Upgrade and validation

   • Upgrade Nova to the fixed version for your branch.
   • Validate in a non-production test environment that your resize workflows still function as expected.
   • During/after upgrade, watch for resize-related errors and any unexpected image conversion behavior.

4. If you can’t patch immediately

   • Reduce exposure by limiting which users/tenants can trigger disk resize operations and by ensuring only trusted image sources are used for root/ephemeral disks.
   • Confirm whether any part of your process allows user-controlled disk image headers to reach the Flat image backend resize path.
   • Use your operational monitoring to detect unusual or repeated resize attempts that could indicate probing.

5. What to monitor

   • Resize operations failing in unusual ways.
   • Any errors in image conversion/resize related components.
   • Unusual resize activity patterns, especially involving root or ephemeral disks.

Severity/score context: reported as HIGH (CVSS 8.2) with impact that includes integrity and availability loss (data destruction risk). Weaknesses are listed as CWE-669 (Reachable Path) and CWE-73 (External Control of File Name or Path) in the record.

Mechanism: By writing a malicious QCOW header to a root or ephemeral disk and then triggering a resize, a user can influence Nova’s Flat image backend to call qemu-img without a format restriction, leading to an unsafe image resize operation. This can destroy data on the host system.

Reachability: described as affecting compute nodes using the Flat image backend (usually with use_cow_images=False). No KEV entry exists for this CVE, and there is no public exploit code on record.

Exploitation maturity: not confirmed as exploited in the provided findings (no KEV/news claim) and no exploit code is known publicly. EPSS is provided as a prediction of 0.3% with flat trend, but this should not be treated as evidence of real-world exploitation.