Bug#1152634: starlet: CVE-2026-116128 CVE-2026-116127 CVE-2026-115866 CVE-2026-115865

[Salvatore Bonaccorso]

Source: starlet
Version: 0.32-1
X-Debbugs-CC: team at security.debian.org
Severity: important
Tags: security upstream

Hi,

The following vulnerabilities were published for starlet.

CVE-2026-116128[0]:
| Starlet versions from 0.20 before 0.33 for Perl allow memory
| exhaustion via unbounded buffering when decoding chunked request
| bodies.  The decoder adds each read to one buffer of unconsumed
| input. Nothing limits the length of a chunk-size line, so a line
| without a CRLF grows the buffer for as long as the client keeps
| sending, and the read timeout restarts after every read. The data of
| a large chunk is also held in the buffer until the whole chunk has
| arrived.  A remote attacker can exhaust a worker's memory with a
| single request.


CVE-2026-116127[1]:
| 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.


CVE-2026-115866[2]:
| Starlet versions from 0.20 before 0.33 for Perl allow CPU exhaustion
| via regular expression backtracking when decoding chunked request
| bodies.  A chunk-size line is matched as a run of hex digits, then
| .* and a CRLF. A run followed by a bare LF and then a CRLF can never
| match, and the engine retries the match once for each digit, so the
| time taken grows with the square of the run length. Nothing limits
| the length of the run, which can span several reads.  A remote
| attacker can occupy a worker for about a minute of CPU time with one
| 128 KiB request, before the application is called.


CVE-2026-115865[3]:
| Starlet versions before 0.33 for Perl allow a request declaring a
| large Content-Length to kill a worker by exhausting memory.  The
| request body is read in a loop that asks sysread for all of the
| remaining declared length at once. Perl grows the read buffer to
| that size before any data arrives, so a length larger than available
| memory makes the worker exit with an uncatchable out of memory error
| before the application is called.  A remote attacker can force a
| worker restart with each request of a few bytes.


If you fix the vulnerabilities please also make sure to include the
CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2026-116128
    https://www.cve.org/CVERecord?id=CVE-2026-116128
[1] https://security-tracker.debian.org/tracker/CVE-2026-116127
    https://www.cve.org/CVERecord?id=CVE-2026-116127
[2] https://security-tracker.debian.org/tracker/CVE-2026-115866
    https://www.cve.org/CVERecord?id=CVE-2026-115866
[3] https://security-tracker.debian.org/tracker/CVE-2026-115865
    https://www.cve.org/CVERecord?id=CVE-2026-115865

Regards,
Salvatore