CVE-2026-115817: 
Linux Debian vulnerability analysis and mitigation

CVE-2026-115817 is a Denial of Service vulnerability in Starman, a high-performance preforking PSGI/Plack web server for Perl. The flaw allows a remote attacker to hold worker processes indefinitely by sending complete HTTP headers followed by a stalled or slowly trickled request body, since read_timeout previously applied only to header reads and no deadline existed for body reads. All Starman versions before 0.4019 are affected. The vulnerability was disclosed on October 25, 2026, with a CVSS category estimate of Medium (GitHub Advisory, Feedly).

The root cause is CWE-770 (Allocation of Resources Without Limits or Throttling): Starman's _prepare_env method reads Content-Length and chunked request bodies using blocking sysread calls with no timeout or deadline (GitHub Advisory). Because read_timeout was scoped only to reading request headers, any client that completed the header phase but then stalled or sent body data one byte at a time could occupy a worker process for an unlimited duration. With Starman's default worker count of five, an attacker needs only five such connections to exhaust the entire worker pool. The fix in version 0.4019 introduces two complementary controls: read_timeout is now applied to each individual body read via Time::HiRes::alarm, and a new body_timeout option (default 300 seconds) enforces a total deadline on the entire body read phase; expiry results in a 408 Request Timeout response without dispatching the application (Commit 89dffd3, Commit a30533c).

Successful exploitation causes complete availability loss for the targeted Starman instance: with only five connections (matching the default worker count), an unauthenticated remote attacker can prevent the server from processing any legitimate requests. There is no confidentiality or integrity impact — the attack is purely a Denial of Service. Applications deployed directly on Starman without a buffering reverse proxy in front are most exposed, as a reverse proxy that buffers full request bodies before forwarding would mitigate the attack (GitHub Advisory, Feedly).

No public proof-of-concept exploit code has been identified, and there is no evidence of in-the-wild exploitation at the time of disclosure (Feedly). The EPSS score is 0.0, reflecting low current exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. Despite the absence of a PoC, the attack technique is straightforward and requires no authentication — any attacker capable of opening TCP connections to the server can exploit it with standard HTTP tooling.

1. Reconnaissance: Identify internet-facing Starman servers (e.g., via HTTP response headers such as Server: Starman/0.xxxx) using tools like Shodan, Censys, or targeted banner grabbing against known Perl/PSGI application endpoints.
2. Establish connections: Open multiple TCP connections (at least five for default Starman deployments) to the target server's HTTP port.
3. Send complete headers with declared body: For each connection, transmit a well-formed HTTP POST request with complete headers including a large Content-Length value (e.g., Content-Length: 100000000000) or a Transfer-Encoding: chunked header, followed by only a few bytes of body data — enough to pass header parsing.
4. Stall or trickle the body: After sending the initial body bytes, stop sending data entirely or send one byte every few seconds. This keeps each worker blocked in a sysread call waiting for the remainder of the body.
5. Exhaust worker pool: With five such stalled connections against a default Starman instance, all worker processes are occupied. The server becomes unable to accept or process new legitimate requests, achieving effective Denial of Service (GitHub Advisory, Commit 89dffd3).

• Network: Multiple long-lived HTTP POST connections from the same or different source IPs with large declared Content-Length values but minimal data transfer; connections that remain open for minutes without completing body transmission.
• Logs: Starman access logs showing POST requests that never complete (no response logged or very delayed responses); absence of application dispatch log entries for requests that have passed header parsing.
• Process: Starman worker processes stuck in blocking I/O (sysread) for extended periods; ps or top showing all worker processes in an uninterruptible wait state with no CPU activity.
• Availability: Sudden drop in successful HTTP responses from the Starman instance; legitimate clients receiving connection refused or timeout errors despite the server process being alive.

Upgrade Starman to version 0.4019 or later, which applies read_timeout to each individual body read and introduces a body_timeout option (default 300 seconds) as a total deadline for reading the entire request body (MetaCPAN, GitHub Advisory). If immediate upgrade is not possible, deploy a buffering reverse proxy (e.g., nginx or HAProxy) in front of Starman configured to fully buffer request bodies before forwarding — this prevents slow clients from ever reaching Starman workers directly. Additionally, configure network-level connection timeouts and rate limiting at the load balancer or firewall to restrict the number of concurrent connections per source IP. When deploying version 0.4019, tune --body-timeout and --read-timeout values to match your application's legitimate upload requirements; set --body-timeout 0 only if clients upload large bodies over slow links directly to Starman.