Bug 2564021 (CVE-2026-116127)

Summary: CVE-2026-116127 perl-starlet: Starlet: HTTP response desynchronization via improper response body handling
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerabilityAssignee: Product Security <prodsec-ir-bot>
Status: NEW --- QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedKeywords: Security
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
A flaw was found in Starlet. The server improperly includes a message body when answering certain Hypertext Transfer Protocol (HTTP) requests, such as HEAD requests or responses that should have no body. A remote attacker could exploit this issue by sending pipelined requests over persistent connections, causing leftover response data to bleed into subsequent responses. This behavior can desynchronize downstream proxy servers, potentially leading to response corruption or serving mismatched data across different clients.
 Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 2565501, 2565502, 2565503    
Bug Blocks:    

Description OSIDB Bzimport 2026-10-30 13:44:32 UTC 
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.