[From nobody Sun Oct 25 23:53:08 2026 Received: (at submit) by bugs.debian.org; 25 Oct 2026 19:35:42 +0000 X-Spam-Checker-Version: SpamAssassin 4.0.1-bugs.debian.org_2005_01_02 (2024-03-25) on buxtehude.debian.org X-Spam-Level: X-Spam-Status: No, score=-107.4 required=4.0 tests=ALL_TRUSTED,BAYES_00, DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, FOURLA,FROMDEVELOPER,SPF_HELO_NONE,SPF_PASS,USER_IN_DKIM_WELCOMELIST autolearn=ham autolearn_force=no version=4.0.1-bugs.debian.org_2005_01_02 X-Spam-Bayes: score:0.0000 Tokens: new, 28; hammy, 150; neutral, 120; spammy, 0. spammytokens: hammytokens:0.000-+--Hx-spam-relays-external:sk:stravin, 0.000-+--H*RT:sk:stravin, 0.000-+--Hx-spam-relays-external:311, 0.000-+--H*RT:311, 0.000-+--H*RT:108 Return-path: <carnil@debian.org> Received: from stravinsky.debian.org ([2001:41b8:202:deb::311:108]:50362) by buxtehude.debian.org with esmtps (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.96) (envelope-from <carnil@debian.org>) id 1xL40N-004vyo-06 for submit@bugs.debian.org; Sun, 25 Oct 2026 19:35:42 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debian.org; s=smtpauto.stravinsky; h=X-Debian-User:Content-Type:MIME-Version:Message-ID: Subject:To:From:Date:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:In-Reply-To:References; bh=lyMf3/m7OuitcWvsgr+RitdzbQKC12MGsVCsdCmqn4A=; b=L9uFjcQ09eHv5AWUKWhI5d0e49 n+1SWhsMI7toh+4KUdF3X9E1hj+Uy9y9W1fd1yzyL2RhK7n4Zj9LPuRXx9IOgmPRCi4Qpi2rl61G1 Xp1tb5HK4EdEv+i0c0UYSYRry9kb2uj6aBgXTtOvihD3B8pW9znwc53Ip4mMZ0qak/fW6X73oLo5c 0woylczOlmV9ukoU4YVjhExTa7YfbanYMaKJMSTNbehEU/Mg6ZVbpyp3Ako1lP/hjLX+uysa+xfWg 51Hnrrom/S3Yi69p/LMmzyw0NTu3tB0G53+YWQosmRsvvuhE9w5aXZf051ArUZR1x0XBRVcXm6IFN hzNYeXwg==; Received: from authenticated-user by stravinsky.debian.org with esmtpsa (TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.96) (envelope-from <carnil@debian.org>) id 1xL40J-0008gl-3C for submit@bugs.debian.org; Sun, 25 Oct 2026 19:35:41 +0000 Received: by eldamar.lan (Postfix, from userid 1000) id 5316EDC032E; Sun, 25 Oct 2026 20:35:39 +0100 (CET) Date: Sun, 25 Oct 2026 20:35:39 +0100 From: Salvatore Bonaccorso <carnil@debian.org> To: submit@bugs.debian.org Subject: starman: CVE-2026-115817 CVE-2026-115822 CVE-2026-115823 CVE-2026-115824 Message-ID: <at5aC2WTUVf0SYnU@eldamar.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Debian-User: carnil Delivered-To: submit@bugs.debian.org Source: starman Version: 0.4018-1 X-Debbugs-CC: team@security.debian.org Severity: important Tags: security upstream Hi, The following vulnerabilities were published for starman. CVE-2026-115817[0]: | Starman versions before 0.4019 for Perl allow a stalled request body | to hold a worker indefinitely, as read_timeout covers only the | headers. Content-Length and chunked request bodies are read with | blocking reads and no deadline. A client that sends complete headers | and then stalls or trickles the body keeps the worker waiting until | it disconnects. A remote attacker can take every worker with a few | such connections, five with the default worker count, so the server | stops answering requests. Version 0.4019 applies read_timeout to | each wait for body data and adds a body_timeout limit, 300 seconds | by default, on the total time to read a body. CVE-2026-115822[1]: | Starman versions before 0.4019 for Perl allow CPU exhaustion via | quadratic regex backtracking when parsing chunked request bodies. | Starman decodes chunked request bodies before calling the | application, matching each chunk-size line with | `s/^(([0-9a-fA-F]+).*\015\012)//`. A line of hex digits followed by | a bare LF and then CRLF never matches, because `.` does not match | LF, and each failed attempt backtracks in time quadratic in the | length of the hex run. Nothing limits the length of the line. A | remote attacker can exhaust worker CPU by sending such requests to | any route. CVE-2026-115823[2]: | Starman versions before 0.4019 for Perl send response bodies for | HEAD requests, desynchronizing responses on keep-alive connections. | For a HEAD request Starman omits chunked framing but still writes | the body returned by the application, on both the array and | streaming response paths. Responses with a 1xx, 204 or 304 status | also carry the body. On a keep-alive or pipelined connection the | client reads those bytes as the start of the next response. A front- | end proxy that reuses upstream connections may then pair responses | with the wrong requests. CVE-2026-115824[3]: | Starman versions before 0.4019 for Perl allow memory exhaustion via | unbounded buffering of chunked request bodies. The chunked body | decoder keeps each chunk in memory until the whole chunk and its | CRLF have arrived, and sets no limit on the length of a chunk-size | line. A client that declares a huge chunk size and streams data, or | sends a chunk-size line that never ends, grows the buffer for as | long as it keeps sending. A remote attacker can exhaust worker | memory with a single connection. 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-115817 https://www.cve.org/CVERecord?id=CVE-2026-115817 [1] https://security-tracker.debian.org/tracker/CVE-2026-115822 https://www.cve.org/CVERecord?id=CVE-2026-115822 [2] https://security-tracker.debian.org/tracker/CVE-2026-115823 https://www.cve.org/CVERecord?id=CVE-2026-115823 [3] https://security-tracker.debian.org/tracker/CVE-2026-115824 https://www.cve.org/CVERecord?id=CVE-2026-115824 Regards, Salvatore ]