Live › vulnerability › CVE-2026-116127
Starlet, a Perl web server, sends a response body to HEAD requests and to 204 and 304 responses. On persistent or pipelined connections the extra bytes corrupt the next response, which can desynchronize a proxy shared across clients.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-30 13:30 UTC. All times on this page are UTC.
Applications running Starlet below 0.33 are affected, most risky when a proxy or load balancer reuses persistent or pipelined connections to the Perl app across different clients. Standalone use with a single client and no shared proxy path is lower risk. Apps that do not use Starlet can skip it.
No product ranges from the sources yet.
perl -MStarlet -e 'print $Starlet::VERSION'Starlet in the cpanfile, cpanfile.snapshot or Makefile.PL of the application0.33 or later (the fix is in versions before 0.33 per the NVD description)Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
Starlet versions before 0.33 for Perl send a body in responses to HEAD requests, corrupting the next response on a persistent or pipelined connection.
The request method is not passed to the response writer, so whatever body the application returns for a HEAD request is sent. With Plack::Middleware::Head the body is empty, but an HTTP/1.1 response without a Content-Length header still gets the chunked encoding terminator. Responses with status 204 or 304 are also sent with their body.
Pipelined GET and HEAD requests keep the connection open even when keep-alive is disabled, which is the default. A client or proxy reading the connection takes the extra bytes as the start of the next response, which may desynchronize a proxy that shares the connection across clients.
This page as .md · .json · in your agent: get_signal("CVE-2026-116127")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.