CVE-2026-111924 in Fleet
Summary
by MITRE • 10/17/2026
Fleet before 4.83.0 contains a denial of service vulnerability that allows unauthenticated attackers to exhaust server memory by sending gzip-compressed request bodies. Attackers can send small, highly compressed requests with Content-Encoding: gzip to unauthenticated endpoints that expand during decoding, crashing the entire Fleet instance.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/17/2026
The identified vulnerability in Elasticsearch Fleet prior to version 4.83.0 represents a critical resource exhaustion flaw rooted in improper handling of decompressed data sizes relative to allocated memory buffers. This specific weakness is classified under CWE-770 as Allocation of Resources Without Limits or Throttling, where the application fails to enforce constraints on the amount of system resources that can be consumed by an external entity. The core technical failure lies in the server's processing pipeline for HTTP requests containing gzip-compressed payloads. When a client submits data with the Content-Encoding: gzip header, the backend service attempts to decompress this payload into memory before further processing or validation occurs. In vulnerable versions of Fleet, there is no mechanism to limit the maximum size of the uncompressed output stream derived from these compressed inputs. This architectural oversight allows an attacker to craft maliciously small request bodies that possess extremely high compression ratios, effectively acting as a zipper bomb designed specifically for this context.
From an operational perspective, this vulnerability enables unauthenticated denial-of-service attacks against the Fleet management interface or associated API endpoints. An adversary can send a series of carefully constructed HTTP requests with minimal byte sizes but massive potential uncompressed expansion factors. As the server processes these requests, it allocates memory proportional to the decompressed size rather than the transmitted size. Because there is no upper bound on this allocation, repeated exploitation attempts rapidly consume available heap space and system RAM. This resource depletion leads to severe performance degradation for legitimate users and ultimately results in a complete crash of the Fleet instance when the operating system or application runtime terminates processes due to out-of-memory conditions. The impact extends beyond simple unavailability; it can lead to data loss if persistent states are not properly saved before termination, and it disrupts critical monitoring and security operations managed by the Fleet agent infrastructure.
This attack vector aligns with MITRE ATT&CK technique T1498 Network Denial of Service, specifically sub-technique T1498.002 which involves resource exhaustion through application layer attacks. The lack of input validation regarding compression ratios and decompressed size limits is a common pattern in web services that prioritize throughput over strict payload sanitization for unauthenticated endpoints. To mitigate this risk, organizations running Fleet versions earlier than 4.83.0 must apply the vendor-provided patch immediately which implements proper bounds checking on decompressed data sizes. Additionally, until patches are applied or during remediation windows, network-level controls such as rate limiting and request size restrictions at the reverse proxy or load balancer layer can help mitigate the impact by capping the maximum allowable uncompressed payload size before it reaches the vulnerable application logic. Administrators should also monitor system memory usage for anomalous spikes correlated with HTTP traffic to detect ongoing exploitation attempts in real-time.