CVE-2026-115638 in Ironic
Summary
by MITRE • 10/23/2026
OpenStack Ironic through 39.0.1 allows a denial of service via a configdrive that results in a very large amount of uncompressed data, aka a gzip bomb.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/23/2026
The vulnerability identified within OpenStack Ironic versions up to and including 39.0.1 represents a significant security risk centered on the handling of configuration drives during node provisioning processes. This flaw is fundamentally rooted in how the system manages compressed archive files, specifically those utilizing gzip compression algorithms. When an administrator or automated process provides a configdrive for deployment onto bare metal nodes, Ironic attempts to decompress and extract the contents of this drive to apply necessary configurations such as cloud-init scripts, network settings, or user data. The critical technical flaw lies in the absence of adequate validation regarding the expansion ratio between the compressed input file and its uncompressed output. This oversight allows an attacker who has control over the configdrive payload to craft a maliciously constructed archive that appears small when compressed but expands into gigabytes or even terabytes of data upon decompression, commonly referred to as a gzip bomb or zip bomb attack vector.
From a technical perspective, this vulnerability exploits the resource-intensive nature of decompression operations without corresponding limits on output size. The system processes the incoming configdrive stream and allocates memory and disk space proportional to the uncompressed content rather than the original file size. Because there is no mechanism in place to monitor or cap the total volume of data being written during this extraction phase, a single maliciously crafted archive can rapidly consume available system resources. This includes exhausting RAM on the conductor nodes responsible for processing these requests and filling up disk partitions where temporary files are stored. The lack of bounds checking means that the application continues decompressing until it hits hard limits imposed by the operating system or hardware, leading to a complete halt in service availability rather than graceful error handling.
The operational impact of this denial-of-service vulnerability is severe for any infrastructure relying on OpenStack Ironic for bare metal provisioning. Since configdrives are often used during critical phases of node lifecycle management such as initial bootstrapping and configuration application, an attack targeting this vector can disrupt the entire provisioning pipeline. Conductor nodes may become unresponsive due to resource exhaustion, preventing them from managing other active instances or handling legitimate requests. This results in a cascading failure where not only is the targeted operation blocked, but broader orchestration capabilities are degraded. In environments with high turnover of bare metal resources, this vulnerability can be exploited repeatedly to maintain persistent denial-of-service conditions, effectively rendering the Ironic service unusable until manual intervention clears the resource locks and recovers system stability.
This flaw aligns closely with CWE-409, which describes improper handling of highly compressed data leading to information disclosure or denial of service through decompression bombs. Furthermore, in terms of adversarial tactics, this behavior maps to MITRE ATT&CK techniques related to Resource Hijacking and Denial of Service via application layer attacks. The attacker leverages the legitimate functionality of configdrive processing to execute a resource exhaustion attack without needing elevated privileges beyond what is required to submit a provisioning request with a custom configdrive. This makes it particularly dangerous in multi-tenant environments where users might have limited access but sufficient rights to trigger node deployments using their own configuration payloads.
Mitigation strategies for this vulnerability primarily involve upgrading the OpenStack Ironic deployment to version 40.0.2 or later, which includes patches designed to validate and limit the size of decompressed data. For organizations unable to immediately upgrade, operational mitigations include implementing strict input validation at the load balancer or API gateway level to reject configdrive files that exceed a reasonable compressed size threshold before they reach the Ironic conductor nodes. Additionally, administrators should enforce resource quotas on compute hosts and conductor nodes using cgroups or similar containerization controls to limit the maximum memory and disk usage per process. Monitoring tools should be configured to alert on unusual spikes in decompression activity or rapid increases in temporary file sizes during provisioning tasks. Ensuring that configdrive uploads are sanitized and validated against known safe patterns can further reduce the attack surface, although software patching remains the most effective long-term solution.