Security Advisories (10)
CVE-2026-116264 (2026-10-28)

MIME::Field::ParamVal versions before 5.521 for Perl allow one invalid Content-Type parameter to hide the parameters after it, including the multipart boundary. Parameter parsing stops at the first parameter whose name it cannot read, such as x:y=1 or a name containing an 8-bit byte, and drops every parameter after it. When the boundary is among them, MIME::Parser keeps the multipart body as a single undecoded part without marking the parse as ambiguous. Mail readers that skip the invalid parameter still find the boundary. A remote sender can hide an attachment from a filter that relies on ambiguous_content() while the recipient's mail client shows it.

CVE-2026-116265 (2026-10-28)

MIME::Field::ParamVal versions before 5.521 for Perl do not flag an ambiguous multipart boundary written as RFC 2231 continuations. The boundary ambiguity checks look only at a plain boundary= parameter, and a boundary split into RFC 2231 sections (boundary*0=, boundary*1= and so on) is joined after they have run. A repeated section number is concatenated rather than reported as a duplicate. From version 5.518, an encoded word or trailing whitespace in such a boundary also goes unflagged, although multipart_boundary() decodes or strips it. A remote sender can make MIME::Parser split a message on a different boundary than other mail readers, hiding an attachment from a filter that relies on ambiguous_content() while the recipient's mail client shows it.

CVE-2026-116266 (2026-10-28)

MIME::Head versions from 5.518 before 5.521 for Perl decode a partly encoded multipart boundary without flagging the parse as ambiguous. The multipart_boundary() method decodes RFC 2047 encoded words anywhere in the boundary, but the ambiguity check only fires when the whole value is one encoded word. A boundary such as abc=?us-ascii?Q?def?= is used as abcdef, and ambiguous_content() returns false. Encoded words are not allowed in parameters, so other mail readers split the message on the literal value. A remote sender can hide an attachment from a filter that relies on ambiguous_content() while the recipient's mail client shows it.

CVE-2026-116267 (2026-10-28)

MIME::Parser versions before 5.521 for Perl allow memory exhaustion via indented error messages from a truncated, deeply nested message. Each stored parser diagnostic is indented by three spaces per nesting level. When a message nested N levels deep ends without its closing boundaries, every level logs an error at its own depth, so the stored diagnostics grow with the square of N. The defaults place no limit on nesting depth.

CVE-2026-116268 (2026-10-28)

MIME::Field::ParamVal versions before 5.521 for Perl allow CPU exhaustion via unclosed comments in header parameters. The comment pattern used to parse Content-Type and Content-Disposition parameters scans from each "(" to the next ")". In a field with no ")", every "(" scans to the end of the header and fails, so parsing takes time quadratic in the header length. The field is parsed again on each attribute lookup, several times per MIME entity. A 40 KB header takes about 7 seconds to parse once.

CVE-2026-116269 (2026-10-28)

MIME::Field::ParamVal versions before 5.521 for Perl turn an RFC 2231 filename with a hyphenated language tag into an empty recommended filename. A parameter such as filename*=utf-8'en-US'payload.exe is converted to an encoded word with the language tag appended to the charset. The decoder strips the language suffix only when it is a single word, so it cannot resolve the charset UTF-8*EN-US and returns an empty string. The recommended_filename() method returns that empty string rather than falling back to the name parameter. Other mail readers return payload.exe. A remote sender can get an attachment past a policy that checks file extensions on the recommended filename.

CVE-2026-116270 (2026-10-28)

MIME::Words versions before 5.521 for Perl allow memory exhaustion via repeated "=?" sequences in decode_mimewords. For each "=?" that does not start a complete encoded word, decode_mimewords appends an error message containing the whole input string to $@. A boundary of 8,000 "=?" pairs (16,000 bytes) adds 8,000 copies of itself to $@, about 128 MB. From version 5.518, MIME::Parser decodes every multipart boundary this way, so a remote sender can exhaust the memory of the parsing process with one Content-Type header.

CVE-2026-116271 (2026-10-28)

MIME::Parser::FileUnder versions before 5.521 for Perl reuse a pre-created output directory and follow symlinks in it, letting local users redirect attachment writes. Each message is written to a directory named msg-<time>-<pid>-<n> under the output base, and an existing directory of that name is used as is. A file name counts as unused when nothing exists at that path, which holds for a dangling symlink, and the body file is then opened in a way that follows the link. When the output base is writable by other users, as with output_under("/tmp"), a local user can pre-create the directory with a symlink named like an attachment. The parser then writes the attachment to the link target with the privileges of the parsing process.

CVE-2026-116272 (2026-10-28)

MIME::Field::ParamVal versions before 5.521 for Perl do not flag a duplicate boundary parameter whose name contains a nested comment. A parameter written boundary((c))="A" or boundary(\))="A" is stored under that literal name rather than as boundary. A second boundary parameter is then not reported as a duplicate, and MIME::Parser splits the message on it. Readers that skip comments as RFC 5322 allows take the first boundary instead. A remote sender can hide an attachment from a filter that relies on ambiguous_content() while the recipient's mail client shows it.

CVE-2026-116273 (2026-10-28)

MIME::Parser versions before 5.521 for Perl set no limit on the number of message parts by default, allowing memory exhaustion. The max_parts option defaulted to -1, which disables the limit, so a parser created with default settings builds an entity for every part however many a message has. Version 5.521 sets max_parts to 1000 and max_depth to 64 by default. Setting either to -1 still removes the limit.

NAME

MIME::Decoder::NBit - encode/decode a "7bit" or "8bit" stream

SYNOPSIS

A generic decoder object; see MIME::Decoder for usage.

DESCRIPTION

This is a MIME::Decoder subclass for the 7bit and 8bit content transfer encodings. These are not "encodings" per se: rather, they are simply assertions of the content of the message. From RFC-2045 Section 6.2.:

Three transformations are currently defined: identity, the "quoted-
printable" encoding, and the "base64" encoding.  The domains are
"binary", "8bit" and "7bit".

The Content-Transfer-Encoding values "7bit", "8bit", and "binary" all
mean that the identity (i.e. NO) encoding transformation has been
performed.  As such, they serve simply as indicators of the domain of
the body data, and provide useful information about the sort of
encoding that might be needed for transmission in a given transport
system.  

In keeping with this: as of MIME-tools 4.x, this class does no modification of its input when encoding; all it does is attempt to detect violations of the 7bit/8bit assertion, and issue a warning (one per message) if any are found.

RFC-2045 Section 2.7 defines legal 7bit data:

"7bit data" refers to data that is all represented as relatively
short lines with 998 octets or less between CRLF line separation
sequences [RFC-821].  No octets with decimal values greater than 127
are allowed and neither are NULs (octets with decimal value 0).  CR
(decimal value 13) and LF (decimal value 10) octets only occur as
part of CRLF line separation sequences.

RFC-2045 Section 2.8 defines legal 8bit data:

"8bit data" refers to data that is all represented as relatively
short lines with 998 octets or less between CRLF line separation
sequences [RFC-821]), but octets with decimal values greater than 127
may be used.  As with "7bit data" CR and LF octets only occur as part
of CRLF line separation sequences and no NULs are allowed.

How decoding is done

The decoder does a line-by-line pass-through from input to output, leaving the data unchanged except that an end-of-line sequence of CRLF is converted to a newline "\n". Given the line-oriented nature of 7bit and 8bit, this seems relatively sensible.

How encoding is done

The encoder does a line-by-line pass-through from input to output, and simply attempts to detect violations of the 7bit/8bit domain. The default action is to warn once per encoding if violations are detected; the warnings may be silenced with the QUIET configuration of MIME::Tools.

SEE ALSO

MIME::Decoder

AUTHOR

Eryq (eryq@zeegee.com), ZeeGee Software Inc (http://www.zeegee.com).

All rights reserved. This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself.