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