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

CVE-2026-115823 is an HTTP response desynchronization vulnerability in Starman, a high-performance preforking PSGI/Plack web server for Perl. Versions before 0.4019 incorrectly send response bodies for HEAD requests and responses with 1xx, 204, or 304 status codes, causing keep-alive connection desynchronization. This was disclosed on October 25, 2026, and assigned by CPANSec. The vulnerability carries a Feedly-estimated severity of HIGH and is classified under CWE-444 (Inconsistent Interpretation of HTTP Requests / HTTP Request Smuggling) (GitHub Advisory, ENISA EUVD).

The root cause (CWE-444) lies in Starman's _finalize_response function in lib/Starman/Server.pm. Starting in version 0.4009, Starman correctly stopped adding chunked framing to HEAD responses, but continued writing the application-returned body bytes to the connection — both for array-style and streaming (object) response bodies. The same flaw affects responses with 1xx, 204, and 304 status codes. On a keep-alive or pipelined HTTP/1.1 connection, the client or upstream proxy reads these spurious body bytes as the beginning of the next response (e.g., HELLOHTTP/1.1 200 OK), causing response-to-request mismatching. The fix introduces a $no_body flag that suppresses body writes and closes body objects without reading them for the affected request/response types (Patch Commit, GitHub Advisory).

Successful exploitation allows an unauthenticated attacker to cause response desynchronization on keep-alive or pipelined connections, resulting in clients receiving response bodies intended for other requests. Front-end proxies that pool upstream connections to Starman may pair responses with incorrect requests, potentially exposing sensitive response data (e.g., authentication tokens, session cookies, or private content) to unintended clients. This constitutes a tampering and information disclosure risk, and in proxy-heavy architectures, could facilitate cache poisoning or session hijacking (GitHub Advisory, ENISA EUVD).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation as of the disclosure date (ENISA EUVD). The EPSS score is 0.0, indicating very low current exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. No threat actor attribution has been reported. Exploitation requires the ability to send HTTP requests over a keep-alive connection to a Starman-backed application, which is a low barrier in internet-facing deployments.

1. Reconnaissance: Identify web applications running on Starman (versions before 0.4019) by examining HTTP response headers (e.g., Server: Starman) or through fingerprinting techniques.
2. Establish keep-alive connection: Open a persistent HTTP/1.1 connection to the target server, ensuring Connection: keep-alive is negotiated.
3. Send a HEAD request (or trigger a no-body status): Issue a HEAD request to any resource that returns a body, or craft a request that elicits a 204 or 304 response from the application.
4. Pipeline a follow-up request: Immediately send a second GET request on the same connection without waiting for the first response to complete.
5. Observe desynchronization: The spurious body bytes from the HEAD/204/304 response are prepended to the second response as seen by the client (e.g., HELLOHTTP/1.1 200 OK ...), causing the client to misparse the response stream.
6. Exploit in proxy context: In environments where a front-end proxy (e.g., nginx, HAProxy) reuses upstream connections to Starman, the desynchronized bytes may cause the proxy to associate a response intended for one client with a different client's request, potentially leaking sensitive data (Patch Commit, GitHub Advisory).

• Network: Unusual HTTP/1.1 pipelined or keep-alive requests containing HEAD requests followed immediately by GET requests to the same Starman backend; responses where body content appears prepended to subsequent response headers (e.g., HELLOHTTP/1.1 200 OK).
• Logs: Access logs showing repeated HEAD requests or requests resulting in 204/304 responses from the same client IP in rapid succession; proxy error logs indicating malformed upstream responses or unexpected response framing.
• Application Behavior: Clients or proxies reporting garbled or mismatched HTTP responses; unexpected content appearing in responses that should have no body (HEAD, 204, 304).

Upgrade Starman to version 0.4019 or later, which correctly suppresses body output for HEAD requests and 1xx/204/304 responses on all response paths (array, object, and streaming). The patch is available via CPAN and the official GitHub repository. No configuration-based workaround is documented; upgrading is the only recommended remediation (MetaCPAN Changelog, GitHub Advisory). As a temporary measure, operators may consider placing a reverse proxy (e.g., nginx) in front of Starman configured to disable connection reuse to the upstream, though this does not fix the underlying flaw.