CVE-2026-116128 in Starlet
Summary
by MITRE • 10/30/2026
Starlet versions from 0.20 before 0.33 for Perl allow memory exhaustion via unbounded buffering when decoding chunked request bodies.
The decoder adds each read to one buffer of unconsumed input. Nothing limits the length of a chunk-size line, so a line without a CRLF grows the buffer for as long as the client keeps sending, and the read timeout restarts after every read. The data of a large chunk is also held in the buffer until the whole chunk has arrived.
A remote attacker can exhaust a worker's memory with a single request.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/30/2026
The vulnerability identified in Starlet versions ranging from 0.20 to just before 0.33 represents a critical resource exhaustion flaw within the Perl-based HTTP server implementation, specifically affecting the handling of chunked transfer encoding during client requests. This issue stems directly from an unbounded buffering mechanism designed to decode incoming request bodies that utilize the chunked format defined in RFC 7230. Under normal operational conditions, this decoding process is intended to accumulate data until a complete logical message unit is formed or processed for further application logic. However, due to insufficient validation and length constraints on specific components of the HTTP protocol stream, particularly regarding how chunk sizes are parsed and buffered, the server fails to enforce memory limits effectively during the ingestion phase.
The technical root cause lies in two distinct but related failures within the decoder's state machine. First, there is no limit imposed on the maximum length of a chunk-size line itself. If an attacker sends a malformed HTTP request where the chunk size indicator does not include the expected Carriage Return and Line Feed sequence immediately after the hexadecimal value, the parser continues to treat subsequent bytes as part of that same chunk identifier rather than recognizing them as data or delimiters. This causes the buffer holding unconsumed input to grow indefinitely as long as the client maintains the connection and continues sending data. Second, even when valid chunks are received, their payloads are held entirely in memory until the entire chunk is fully arrived before being processed or released. While this behavior might be acceptable for small payloads under normal circumstances, it becomes a severe liability when combined with the first flaw, as there is no upper bound on how much data can accumulate in these buffers during a single connection session.
From an operational perspective, this vulnerability enables a remote attacker to execute a Denial of Service attack against any service relying on Starlet for HTTP processing. By crafting a malicious request that exploits the unbounded growth of the input buffer, an adversary can force the worker process consuming the request to allocate increasingly large amounts of RAM. The situation is exacerbated by the fact that read timeouts are reset after every successful read operation from the socket. This means that as long as the attacker continues to send data at a rate sufficient to keep the connection alive and trigger new reads, the server will not time out or disconnect the client automatically. Consequently, the worker process remains occupied with this single request while its memory footprint expands until it hits system limits, leading to an Out of Memory condition that crashes the worker and potentially destabilizes the entire application stack if other workers are similarly affected or if swap space is exhausted.
This vulnerability aligns closely with Common Weakness Enumeration category CWE-400, which describes Uncontrolled Resource Consumption, specifically manifesting as a resource exhaustion scenario where memory resources are depleted by an external actor without adequate controls to limit consumption per connection. In the context of the MITRE ATT&CK framework, this behavior is characteristic of T1498 Network Denial of Service, particularly sub-technique T1498.002 which involves indirect network flooding or resource exhaustion through protocol abuse rather than simple bandwidth saturation. The attack vector allows for a low-bandwidth but high-resource impact strategy that can be difficult to detect using standard traffic volume monitoring tools because the connection remains active and technically valid in terms of TCP state, even though it is maliciously consuming server-side resources.
Mitigation strategies must focus on enforcing strict limits on buffer sizes and chunk parsing logic within the Starlet or underlying HTTP parser modules used by Perl applications. For organizations unable to immediately upgrade past version 0.33, implementing a reverse proxy such as Nginx in front of the Starlet workers can provide an effective defense layer. The reverse proxy should be configured with strict limits on request body size and chunked encoding handling parameters, effectively dropping or rejecting malformed requests before they reach the vulnerable Perl worker processes. Additionally, configuring aggressive connection timeouts that do not reset based solely on data receipt but rather enforce a maximum idle time for incomplete headers can help mitigate the impact of this specific attack vector by forcing disconnection of clients that take too long to complete their request structure. Upgrading to Starlet version 0.33 or later is the definitive solution, as these versions address the unbounded buffering issue and implement proper constraints on chunk size line parsing to prevent memory exhaustion attacks.