Live › vulnerability › CVE-2026-116266
Go to dashboardMIME::Head for Perl decodes RFC 2047 encoded words inside a multipart boundary but skips the ambiguity check unless the whole boundary is one encoded word. A crafted email can therefore slip an attachment past a filter that relies on ambiguous_content() while the recipient's mail client still displays it.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-28 18:34 UTC. All times on this page are UTC.
Teams that use MIME::Head to inspect or filter incoming multipart email, where a security decision depends on ambiguous_content(). Mail-handling code that does not use this module or that uses versions outside 5.518 to 5.521 is not affected.
No product ranges from the sources yet.
perl -MMIME::Head -e 'print $MIME::Head::VERSION'multipart_boundary() and ambiguous_content() to see whether mail filtering depends on them5.521 or laterEach row is the first time that source carried this signal. The analyst’s rows are its own findings.
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.
This page as .md · .json · in your agent: get_signal("CVE-2026-116266")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.