CVE-2026-40251
Out-of-Bounds Panic in Incus Storage Volume Import
Publication date: 2026-05-06
Last updated on: 2026-05-07
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| linuxcontainers | incus | to 7.0.0 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-129 | The product uses untrusted input when calculating or using an array index, but the product does not validate or incorrectly validates the index to ensure the index references a valid position within the array. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
This vulnerability exists in Incus, a system container and virtual machine manager, in versions before 7.0.0. It is caused by missing validation logic in the storage volume import process, specifically in the backup restore subsystem. The issue arises from an incorrect bounds check when indexing snapshot metadata arrays, which can lead to an out-of-bounds panic.
An authenticated user with access to the storage volume feature can exploit this by submitting a specially crafted backup archive containing physical snapshot directories along with a tampered index.yaml file that has empty or truncated snapshot metadata arrays. This causes the Incus daemon to access invalid memory locations and crash.
Repeated exploitation of this flaw can keep the Incus daemon offline, resulting in a denial of service condition. The vulnerability is fixed in version 7.0.0.
How can this vulnerability impact me? :
This vulnerability can cause the Incus daemon to crash repeatedly, leading to a denial of service (DoS) condition. An attacker who is authenticated and has access to the storage volume feature can exploit this to keep the system offline.
The impact is primarily availability-related, as the service managing containers and virtual machines becomes unavailable, potentially disrupting operations that depend on these services.
What immediate steps should I take to mitigate this vulnerability?
To mitigate this vulnerability, upgrade the Incus system container and virtual machine manager to version 7.0.0 or later, where the issue has been fixed.
Until the upgrade can be performed, restrict authenticated users' access to the storage volume feature to prevent exploitation.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
The vulnerability allows an authenticated user with access to the storage volume feature to cause the Incus daemon to crash, resulting in a denial-of-service condition. This impacts system availability but does not directly disclose or modify sensitive data.
Since the vulnerability primarily affects availability and does not involve unauthorized access to or leakage of personal or protected health information, its impact on compliance with standards like GDPR or HIPAA is indirect and limited to potential service disruption.
Organizations relying on Incus for critical services should consider the availability impact in their risk assessments and ensure timely patching to maintain compliance with availability requirements in these regulations.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability involves an out-of-bounds panic in the Incus daemon triggered by submitting a specially crafted backup archive with tampered snapshot metadata. Detection would involve monitoring for Incus daemon crashes or denial-of-service symptoms when processing storage volume backups or migrations.
Since the issue is triggered by malformed backup archives, one detection approach is to verify the version of Incus running on your system. Versions prior to 7.0.0 are vulnerable.
You can check the Incus version with the command:
- incus --version
To detect if the daemon is crashing due to this vulnerability, monitor system logs for Incus daemon crashes or panic messages related to storage volume imports or backup restores.
For example, you can use:
- journalctl -u incus -f
or check the system log files for crash traces.
Additionally, to proactively detect attempts to exploit this vulnerability, inspect backup archives before import to ensure snapshot metadata arrays are not empty or truncated. This requires custom scripting or manual validation of the backup archive's index.yaml file.