Source: libhttp-body-perl Version: 1.23-1 X-Debbugs-CC: [email protected] Severity: important Tags: security upstream
Hi, The following vulnerabilities were published for libhttp-body-perl. CVE-2026-116131[0]: | HTTP::Body versions before 1.23_01 for Perl allow memory and | temporary file exhaustion via an unlimited number of form fields and | multipart parts. The urlencoded parser splits the whole body on its | separators at once, creating one scalar per separator before any | field is stored. This costs about 90 bytes of memory per separator | byte. The multipart parser creates a temporary file for every part | that carries a filename. Neither parser limits how many fields or | parts a body may hold. A remote attacker can exhaust worker memory | with a body made of separators, or create thousands of temporary | files with one request of small file parts. CVE-2026-116132[1]: | HTTP::Body versions before 1.23_01 for Perl leave the temporary file | of an incomplete multipart upload on disk. The multipart parser | creates a temporary file as soon as a file part starts, but adds it | to the upload list only when the part completes. Uploads are only | ever deleted from that list, by the cleanup option or by the caller, | so a body that ends inside a file part leaves its temporary file | where nothing can find it. A remote attacker can fill the temporary | directory by repeating such requests, leaving one file behind for | each. CVE-2026-116133[2]: | HTTP::Body versions before 1.23_01 for Perl allow CPU exhaustion via | quadratic rescanning of a multipart body with a missing or malformed | boundary. Before the first part, and between parts, the multipart | parser searches the whole buffered body for the next boundary. On a | miss it keeps everything and searches again from the start when the | next chunk arrives. A body with no boundary, or with a delimiter | followed by neither CRLF nor "--", is therefore rescanned on every | chunk, taking time quadratic in its size. A remote attacker can | exhaust worker CPU with a few such requests. CVE-2026-116134[3]: | HTTP::Body versions before 1.23_01 for Perl allow memory exhaustion | via an unbounded multipart part header block. The multipart parser | takes everything up to the first blank line after a boundary as the | part's header block, with no limit on its size or number of lines. | Every line is stored in the part's header hash, so a block of short | lines costs about 60 bytes of memory per input byte. A remote | attacker can exhaust worker memory with a single request. CVE-2026-116135[4]: | HTTP::Body versions before 1.23_01 for Perl drop mixed-case percent | escapes from urlencoded form fields instead of decoding them. The | decode table holds only the all-lowercase and all-uppercase spelling | of each hex pair, while the escape pattern matches either case. An | escape such as %aB finds no entry and is replaced with nothing, | joining the bytes on either side. Hex digits in percent escapes are | case-insensitive, and conforming decoders return the byte. A remote | attacker can send a field name or value that a conforming decoder in | front of the application reads differently, so that pass%aBword | reaches the application as password. CVE-2026-116285[5]: | HTTP::Body versions before 1.23_01 for Perl allow CPU exhaustion via | quadratic regex backtracking when parsing chunked request bodies. | In chunked mode, used when no content length is given, add() matches | each chunk-size line with `/^([\da-fA-F]+).*\x0D\x0A/`. On a line of | hex digits whose first LF has no CR before it, the digits and `.*` | backtrack against each other, so a single add() takes time quadratic | in the line's length. Nothing limits how long the line can be. A | remote attacker can exhaust CPU in applications that pass chunked | request bodies to HTTP::Body. CVE-2026-116531[6]: | HTTP::Body versions before 1.23_01 for Perl lose track of chunk | boundaries in chunked request bodies when a read ends inside a | chunk. In chunked mode, used when no content length is given, add() | treats a chunk as complete once the buffer is as long as the chunk's | declared size, but the buffer still holds the chunk-size line. When | a read ends in the last bytes of a chunk, add() takes the chunk | short and parses the leftover data as the next chunk-size line. A | remote attacker can make a chunked body never complete, hanging a | server that reads until the body is done, and may make it complete | early, leaving the remaining bytes to be read as the next request. CVE-2026-117500[7]: | HTTP::Body versions before 1.24_01 for Perl allow CPU exhaustion via | regex backtracking on the filename of a multipart upload. For every | file part, the multipart parser finds the suffix of the uploaded | filename by matching the default $basename_regexp, | qr/[^.]+(\.[^\\\/]+)$/, against the whole basename. A basename made | of many dots and ending in a backslash makes the regex backtrack in | time quadratic in its length. A remote attacker can exhaust CPU | with one request, as a basename of about 32 KB takes several seconds | to match and every file part is matched separately. CVE-2026-117501[8]: | HTTP::Body versions before 1.24_01 for Perl allow memory exhaustion | via unbounded buffering of chunked request bodies. In chunked mode, | used when no content length is given, add() holds each chunk in | memory until all of it has arrived. A line that is not a chunk-size | line, a size line without CRLF, or a size too large to fit an | integer leaves the parser waiting forever, and every later add() | grows the buffer. A remote attacker can exhaust memory in | applications that pass chunked request bodies to HTTP::Body. 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-116131 https://www.cve.org/CVERecord?id=CVE-2026-116131 [1] https://security-tracker.debian.org/tracker/CVE-2026-116132 https://www.cve.org/CVERecord?id=CVE-2026-116132 [2] https://security-tracker.debian.org/tracker/CVE-2026-116133 https://www.cve.org/CVERecord?id=CVE-2026-116133 [3] https://security-tracker.debian.org/tracker/CVE-2026-116134 https://www.cve.org/CVERecord?id=CVE-2026-116134 [4] https://security-tracker.debian.org/tracker/CVE-2026-116135 https://www.cve.org/CVERecord?id=CVE-2026-116135 [5] https://security-tracker.debian.org/tracker/CVE-2026-116285 https://www.cve.org/CVERecord?id=CVE-2026-116285 [6] https://security-tracker.debian.org/tracker/CVE-2026-116531 https://www.cve.org/CVERecord?id=CVE-2026-116531 [7] https://security-tracker.debian.org/tracker/CVE-2026-117500 https://www.cve.org/CVERecord?id=CVE-2026-117500 [8] https://security-tracker.debian.org/tracker/CVE-2026-117501 https://www.cve.org/CVERecord?id=CVE-2026-117501 Regards, Salvatore
