CVE-2026-40561
HTTP Request Smuggling in Starlet Perl
Publication date: 2026-05-03
Last updated on: 2026-05-06
Assigner: CPANSec
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| kazuho | starlet | to 0.31 (inc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-444 | The product acts as an intermediary HTTP agent (such as a proxy or firewall) in the data flow between two entities such as a client and server, but it does not interpret malformed HTTP requests or responses in ways that are consistent with how the messages will be processed by those entities that are at the ultimate destination. |
Attack-Flow Graph
AI Powered Q&A
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
The provided information does not specify how the HTTP Request Smuggling vulnerability in Starlet affects compliance with common standards and regulations such as GDPR or HIPAA.
Can you explain this vulnerability to me?
This vulnerability exists in Starlet versions through 0.31 for Perl, where the server incorrectly prioritizes the Content-Length header over the Transfer-Encoding: chunked header when both are present in an HTTP request.
According to the HTTP specification (RFC 7230 section 3.3.3), the Transfer-Encoding header must take precedence over Content-Length. Starlet's improper handling allows an attacker to perform HTTP request smuggling by sending crafted requests that exploit this header precedence issue.
HTTP request smuggling can be used to bypass security controls by smuggling malicious requests through front-end reverse proxies that rely on Starlet, potentially leading to unauthorized actions or data exposure.
How can this vulnerability impact me? :
This vulnerability can allow an attacker to smuggle malicious HTTP requests through a front-end reverse proxy that uses Starlet, potentially bypassing security controls.
The attacker could exploit this to perform unauthorized actions, access sensitive information, or interfere with the normal operation of the web server or applications behind the proxy.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by sending crafted HTTP requests that include both Transfer-Encoding and Content-Length headers to the Starlet server and observing the server's response.
Specifically, you can test if the server improperly prioritizes Content-Length over Transfer-Encoding by sending requests with both headers present and checking if the server accepts the request instead of rejecting it.
A practical approach is to use tools like curl or netcat to manually craft such HTTP requests.
- Example command using netcat to send a request with both headers: ``` echo -e "POST / HTTP/1.1\r\nHost: vulnerable-server\r\nContent-Length: 10\r\nTransfer-Encoding: chunked\r\n\r\n0\r\n\r\n" | nc vulnerable-server 80 ```
- If the server responds with a 400 Bad Request, it is correctly handling the headers; if it accepts the request, it may be vulnerable.
What immediate steps should I take to mitigate this vulnerability?
To mitigate this vulnerability, immediately update the Starlet server to a version that includes the patch which denies requests containing both Transfer-Encoding and Content-Length headers.
The patch enforces compliance with HTTP/1.1 specifications by rejecting such malformed requests with a 400 Bad Request response.
If updating is not immediately possible, consider implementing front-end reverse proxy rules to detect and block requests containing both headers to prevent HTTP request smuggling.