CVE-2026-115866 in Starlet
Summary
by MITRE • 10/30/2026
Starlet versions from 0.20 before 0.33 for Perl allow CPU exhaustion via regular expression backtracking when decoding chunked request bodies.
A chunk-size line is matched as a run of hex digits, then .* and a CRLF. A run followed by a bare LF and then a CRLF can never match, and the engine retries the match once for each digit, so the time taken grows with the square of the run length. Nothing limits the length of the run, which can span several reads.
A remote attacker can occupy a worker for about a minute of CPU time with one 128 KiB request, before the application is called.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/30/2026
The vulnerability identified in Starlet versions ranging from 0.20 to just prior to 0.33 represents a significant availability risk stemming from inefficient regular expression handling within the HTTP chunked transfer encoding parser. This flaw allows for CPU exhaustion attacks, commonly referred to as ReDoS or Regular Expression Denial of Service, where an attacker can manipulate input data to cause excessive computational overhead in the server process. The core technical issue lies in how the application parses the size line associated with each chunk of a request body. Specifically, the parser employs a regular expression pattern that attempts to match a sequence of hexadecimal digits followed by any characters and then a carriage return and line feed sequence. This design choice creates a catastrophic backtracking scenario when presented with malformed input data that closely resembles valid hex sequences but ultimately fails to meet all criteria for a successful match.
When the parser encounters a chunk-size line consisting of a long run of hexadecimal digits, it initially attempts to satisfy the pattern by matching those digits against the first part of the regular expression. However, if the subsequent characters do not conform strictly to the expected format—specifically if there is a bare line feed followed by a carriage return rather than the standard sequence—the match fails at that point. Because the regex engine uses backtracking algorithms, it does not immediately reject the input as invalid. Instead, it systematically retries the match one character position further along the string of hex digits to see if an alternative alignment might succeed. This process repeats for every digit in the run, resulting in a time complexity that grows quadratically with respect to the length of the hexadecimal sequence. Since there is no upper limit imposed on the length of this input stream during parsing, an attacker can construct requests with arbitrarily long hex sequences to maximize processing time before any application logic is invoked.
The operational impact of this vulnerability is severe in terms of service availability and resource consumption. A remote attacker does not require authentication or complex exploit chains; a single HTTP request containing approximately 128 KiB of specifically crafted data can occupy a worker process for roughly one minute of CPU time. In environments where Starlet handles multiple concurrent connections, such as typical web hosting or API gateway scenarios, this behavior can rapidly deplete available processing resources. If an attacker sends multiple such requests simultaneously, they can effectively starve legitimate users by monopolizing the server's CPU capacity and worker threads. This leads to a denial of service condition where responsive services become unavailable, causing timeouts for genuine clients and potentially crashing the application if resource limits are exceeded or if the system becomes unresponsive due to high load.
From a classification perspective, this vulnerability aligns with CWE-400, which covers Uncontrolled Resource Consumption, specifically highlighting how inefficient algorithms can lead to excessive CPU usage. It also maps directly to MITRE ATT&CK technique T1496, known as Resource Hijacking, where attackers consume resources to disrupt service availability or interfere with other processes. The lack of input validation regarding the length and structure of chunk headers exemplifies CWE-20, Improper Input Validation, as the system fails to restrict the size of incoming data fields that are processed by computationally expensive operations.
Mitigation strategies must focus on both immediate patching and long-term defensive coding practices. The primary remediation is to upgrade Starlet to version 0.33 or later, where this specific regular expression handling has been corrected to prevent backtracking exploitation. For systems unable to update immediately, implementing a Web Application Firewall with rules that detect unusually large chunk-size headers can provide an additional layer of defense by dropping malformed requests before they reach the application logic. Furthermore developers should avoid using complex regex patterns for parsing structured data like HTTP headers; instead, manual string manipulation or dedicated parsers designed for performance and safety are recommended to eliminate backtracking risks entirely. Ensuring that input validation includes strict length limits on all header fields is also critical to preventing similar vulnerabilities in other components of the stack.