CVE-2026-40560: Starman HTTP Request Smuggling Flaw

CVE-2026-40560 Overview

CVE-2026-40560 is an HTTP Request Smuggling vulnerability in Starman, a high-performance preforking PSGI/Plack web server for Perl applications. Versions prior to 0.4018 incorrectly prioritize the Content-Length header over Transfer-Encoding: chunked when both headers are present in an HTTP request. This violates RFC 7230 Section 3.3.3, which mandates that Transfer-Encoding must take precedence.

An attacker can exploit this header precedence issue to smuggle malicious HTTP requests through front-end reverse proxies, potentially leading to unauthorized access, cache poisoning, or bypassing security controls.

Critical Impact

Attackers can exploit this HTTP Request Smuggling vulnerability to bypass security controls, poison web caches, and hijack user sessions by smuggling malicious requests through front-end proxies that correctly follow RFC 7230.

Affected Products

• Starman versions prior to 0.4018
• Perl applications using vulnerable Starman versions as PSGI server
• Deployments with front-end reverse proxies (nginx, HAProxy, etc.) forwarding to Starman

Discovery Timeline

• 2026-04-29 - CVE-2026-40560 published to NVD
• 2026-04-29 - Last updated in NVD database

Technical Details for CVE-2026-40560

Vulnerability Analysis

HTTP Request Smuggling occurs when front-end and back-end servers disagree on where one HTTP request ends and another begins. This vulnerability (CWE-444: Inconsistent Interpretation of HTTP Requests) arises from Starman's improper handling of conflicting HTTP headers.

When an HTTP request contains both Content-Length and Transfer-Encoding: chunked headers, RFC 7230 Section 3.3.3 explicitly states that Transfer-Encoding must take precedence and Content-Length should be ignored. Starman violated this specification by prioritizing Content-Length over Transfer-Encoding: chunked.

This discrepancy creates a desynchronization attack vector: if a front-end proxy (correctly following RFC 7230) interprets the request body using Transfer-Encoding, while Starman interprets it using Content-Length, an attacker can craft requests where the body interpreted by one system contains a complete HTTP request that the other system treats as a new request.

Root Cause

The root cause lies in the request body parsing logic in lib/Starman/Server.pm. The original code structure checked for CONTENT_LENGTH first and only processed chunked encoding as an elsif fallback:

if (my $cl = $env->{CONTENT_LENGTH}) {
    # Process using Content-Length
} elsif ($chunked) {
    # Process using chunked encoding
}

This conditional ordering meant that whenever both headers were present, Content-Length would always be used, violating RFC 7230 requirements.

Attack Vector

This vulnerability is exploitable over the network without authentication. An attacker positioned to send HTTP requests through a front-end proxy to a vulnerable Starman server can craft specially malformed requests containing both Content-Length and Transfer-Encoding: chunked headers.

The attack enables:

• Request hijacking: Smuggling requests that get processed with another user's session
• Cache poisoning: Injecting malicious content into web caches
• Security bypass: Circumventing front-end WAF rules and access controls
• Credential theft: Capturing credentials from other users' requests

The fix implemented in Starman 0.4018 corrects the conditional logic to check for chunked encoding first:

 
     my $chunked = do { no warnings; lc delete $env->{HTTP_TRANSFER_ENCODING} eq 'chunked' };
 
-    if (my $cl = $env->{CONTENT_LENGTH}) {
-        my $buf = Plack::TempBuffer->new($cl);
-        while ($cl > 0) {
-            my($chunk, $read) = $get_chunk->();
-
-            if ( !defined $read || $read == 0 ) {
-                die "Read error: $!\n";
-            }
-
-            $cl -= $read;
-            $buf->print($chunk);
-        }
-        $env->{'psgi.input'} = $buf->rewind;
-    } elsif ($chunked) {
+    if ($chunked) {
         my $buf = Plack::TempBuffer->new;
         my $chunk_buffer = '';
         my $length;

Source: GitHub Starman Patch

Detection Methods for CVE-2026-40560

Indicators of Compromise

• HTTP requests containing both Content-Length and Transfer-Encoding: chunked headers simultaneously
• Unexpected HTTP requests appearing in application logs that don't correspond to legitimate client activity
• Web cache entries containing malicious or unexpected content
• Session-related anomalies where users report seeing other users' data

Detection Strategies

• Monitor HTTP access logs for requests containing conflicting Content-Length and Transfer-Encoding headers
• Implement WAF rules to detect and block requests with both body-length specification headers
• Review Starman version deployed across infrastructure using cpan -D Starman or checking META.json
• Audit reverse proxy configurations for request normalization settings

Monitoring Recommendations

• Configure front-end proxies to log and alert on ambiguous HTTP requests with conflicting headers
• Enable detailed request logging on Starman instances to capture header information
• Monitor for unusual patterns in application behavior that could indicate request smuggling attempts
• Set up SIEM rules to correlate suspicious HTTP header patterns across proxy and application server logs

How to Mitigate CVE-2026-40560

Immediate Actions Required

• Upgrade Starman to version 0.4018 or later immediately using cpanm Starman@0.4018
• Audit all Perl applications using Starman as the PSGI server
• Review front-end proxy configurations for request header normalization capabilities
• Test the deployment with HTTP request smuggling detection tools after patching

Patch Information

The vulnerability has been addressed in Starman version 0.4018. The patch modifies the request body parsing logic in lib/Starman/Server.pm to check for Transfer-Encoding: chunked before Content-Length, ensuring compliance with RFC 7230 Section 3.3.3.

Detailed patch information is available in the MetaCPAN Starman Changes and the GitHub commit.

Workarounds

• Configure front-end reverse proxies (nginx, HAProxy, Apache) to reject or normalize requests containing both Content-Length and Transfer-Encoding headers
• Implement WAF rules to block HTTP requests with conflicting body-length headers
• If possible, ensure the front-end proxy strips Transfer-Encoding headers before forwarding to Starman
• Consider using HTTP/2 between clients and proxies where request smuggling via these headers is not possible

# nginx configuration to reject ambiguous requests
# Add to server block
if ($http_transfer_encoding ~* "chunked") {
    set $smuggle_check "chunked";
}
if ($content_length) {
    set $smuggle_check "${smuggle_check}+length";
}
if ($smuggle_check = "chunked+length") {
    return 400;
}