CVE-2026-115822 in Starman
Summary
by MITRE • 10/25/2026
Starman versions before 0.4019 for Perl allow CPU exhaustion via quadratic regex backtracking when parsing chunked request bodies.
Starman decodes chunked request bodies before calling the application, matching each chunk-size line with `s/^(([0-9a-fA-F]+).*\015\012)//`. A line of hex digits followed by a bare LF and then CRLF never matches, because `.` does not match LF, and each failed attempt backtracks in time quadratic in the length of the hex run. Nothing limits the length of the line.
A remote attacker can exhaust worker CPU by sending such requests to any route.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/25/2026
The vulnerability identified in Starman versions prior to 0.4019 represents a critical server-side resource exhaustion flaw rooted in inefficient regular expression handling within HTTP request parsing logic. As an implementation of the PSGI web server interface for Perl, Starman is responsible for decoding incoming HTTP requests before passing them to the underlying application framework. The specific defect occurs during the processing of chunked transfer encoding bodies, where the server attempts to parse and validate each chunk size line using a regular expression pattern defined as s/^(([0-9a-fA-F]+).*\015\012)//. This regex is designed to match hexadecimal digits representing the chunk length, followed by any characters, and terminated by carriage return and newline sequences that signify the end of the header line in HTTP protocols.
The technical root cause lies in the interaction between the regular expression engine's backtracking behavior and specific malformed input structures. The pattern includes a greedy quantifier . intended to match arbitrary content after the hex digits but before the CRLF terminator. However, because the dot metacharacter does not inherently match newline characters by default in Perl regexes, inputs consisting of a long sequence of hexadecimal digits followed immediately by a bare line feed (LF) and then a carriage return-line feed (CRLF) sequence fail to match as intended. Instead of failing fast, the regex engine engages in catastrophic backtracking. It attempts every possible combination of characters for the . portion before concluding that no valid CRLF follows within the expected constraints. This results in computational complexity that scales quadratically with respect to the length of the hexadecimal string provided by the attacker.
From an operational perspective, this flaw enables a remote unauthenticated denial-of-service attack against any route served by Starman. An adversary can craft HTTP requests containing extremely long chunk-size headers composed entirely of valid hexadecimal characters but structured such that they trigger the backtracking loop described above. Since there is no upper limit imposed on the length of these lines during parsing, an attacker can send a relatively small payload with thousands or millions of hex digits to consume significant CPU resources on the worker processes handling the request. This leads to complete exhaustion of available processing capacity for those workers, effectively rendering the service unavailable to legitimate users without requiring any authentication credentials.
This vulnerability aligns closely with CWE-400, which classifies issues related to uncontrolled resource consumption, and specifically maps to ATT&CK technique T1496, Resource Hijacking via Denial of Service. The lack of input validation on the chunk size line length allows for a straightforward exploitation path that targets the server's processing capabilities rather than its data integrity or confidentiality mechanisms. Mitigation requires upgrading Starman to version 0.4019 or later, where this regular expression logic has been corrected to prevent quadratic backtracking behavior. Additionally, administrators should implement rate limiting and request size restrictions at the network perimeter using reverse proxies such as Nginx or Apache HTTP Server to filter out malformed requests before they reach the Perl application server, thereby adding a layer of defense-in-depth against similar regex-based denial-of-service vectors in other services that may share comparable parsing logic.