CVE-2026-115823 in Starman
Summary
by MITRE • 10/25/2026
Starman versions before 0.4019 for Perl send response bodies for HEAD requests, desynchronizing responses on keep-alive connections.
For a HEAD request Starman omits chunked framing but still writes the body returned by the application, on both the array and streaming response paths. Responses with a 1xx, 204 or 304 status also carry the body.
On a keep-alive or pipelined connection the client reads those bytes as the start of the next response. A front-end proxy that reuses upstream connections may then pair responses with the wrong requests.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/25/2026
The vulnerability identified in Starman versions prior to 0.4019 represents a critical protocol-level flaw within the Perl-based HTTP server implementation, specifically affecting how HEAD request responses are handled on persistent keep-alive connections. This issue stems from an incorrect adherence to Hypertext Transfer Protocol standards regarding response formatting and body transmission. When a client issues a HEAD request, which by definition requests only headers and no message body, Starman fails to suppress the actual data payload generated by the backend application. Instead of terminating the HTTP transaction immediately after sending the header section containing metadata such as Content-Length or transfer encoding details, the server proceeds to write the full response body to the socket stream. This behavior violates RFC 7231 and related specifications that mandate HEAD responses must not include a message body, thereby creating a fundamental desynchronization between what the client expects and what it receives from the server.
The technical mechanism of this flaw involves both array-based and streaming response paths within Starman's architecture. Regardless of whether the application returns data as an in-memory array or streams it dynamically, the server logic erroneously includes these bytes in the output for HEAD requests. Furthermore, the bug extends beyond standard 200 OK responses to include other status codes that typically imply no body content, such as informational 1xx statuses, No Content (204), and Not Modified (304). In a typical HTTP/1.1 environment utilizing keep-alive connections, where multiple requests can be sent over the same TCP connection without re-establishing it, this erroneous transmission of data has severe consequences for protocol state management. The client socket buffer fills with bytes that are not part of any valid response structure because HEAD responses should end after the headers.
The operational impact of this vulnerability is particularly acute in environments employing keep-alive or HTTP pipelining features. When a client receives these unexpected body bytes following a HEAD request, it interprets them as the beginning of the subsequent response on that same connection. This leads to a state desynchronization where the client's parser becomes confused about message boundaries. For front-end proxies and load balancers that reuse upstream connections to improve performance, this flaw can cause catastrophic misrouting of responses. The proxy may associate the stray body bytes from one request with the headers or data of a completely different subsequent request. This mismatch results in clients receiving corrupted data, incomplete pages, or HTTP parsing errors, effectively breaking the reliability and integrity of web services relying on Starman for high-throughput delivery.
From a security perspective, this vulnerability aligns closely with CWE-20 Improper Input Validation, as the server fails to properly validate the request method against expected response structures, leading to improper output handling. It also relates to CWE-134 Use of Externally-Controlled Format String if one considers the misinterpretation of data streams as a form of format confusion, though more accurately it reflects CWE-697 Incorrect Comparison due to the failure in distinguishing between HEAD and GET response expectations. In terms of MITRE ATT&CK mapping, this behavior facilitates protocol-level attacks that could potentially be leveraged for cache poisoning or request smuggling scenarios if combined with other misconfigurations, although its primary impact is denial of service through connection state corruption rather than direct data exfiltration.
Mitigation requires an immediate upgrade to Starman version 0.4019 or later, where the developers have corrected the logic to ensure that HEAD requests and responses for status codes like 204 and 304 do not transmit any body content. Administrators should also review their application code to ensure compliance with HTTP standards by explicitly handling these edge cases if upgrading is temporarily unfeasible, though patching remains the only robust solution. Additionally, implementing strict timeout policies on keep-alive connections can help mitigate the window of exposure by forcing connection resets before desynchronization causes significant data corruption. Regular auditing of server configurations against current RFC guidelines is recommended to prevent similar protocol-level vulnerabilities in future deployments.