Security Advisories (4)
CVE-2026-4176 (2026-03-29)

Perl versions from 5.9.4 before 5.40.4-RC1, from 5.41.0 before 5.42.2-RC1, from 5.43.0 before 5.43.9 contain a vulnerable version of Compress::Raw::Zlib. Compress::Raw::Zlib is included in the Perl package as a dual-life core module, and is vulnerable to CVE-2026-3381 due to a vendored version of zlib which has several vulnerabilities, including CVE-2026-27171. The bundled Compress::Raw::Zlib was updated to version 2.221 in Perl blead commit c75ae9cc164205e1b6d6dbd57bd2c65c8593fe94.

CVE-2026-57432 (2026-07-13)

Perl versions through 5.43.10 have an integer overflow in S_measure_struct leading to an out-of-bounds heap read in pack and unpack. S_measure_struct adds each item's size times its repeat count to a running total with no overflow check, so a large repeat count in a pack or unpack template wraps the signed SSize_t total negative. The @, X, and x position codes then guard their moves with a signed length comparison that passes when the length is negative, advancing the buffer pointer out of bounds. A template derived from untrusted input can read heap memory past the buffer and return it to the caller.

CVE-2026-8376 (2026-05-25)

Perl versions through 5.43.10 have a heap buffer overflow when compiling regular expressions with a repeated fixed string on 32-bit builds. Perl_study_chunk in regcomp_study.c checked the size of the joined substring buffer in characters rather than bytes. For a quantified fixed substring with a large minimum count, the byte length mincount * l could overflow SSize_t, producing an undersized SvGROW allocation; the subsequent copy writes past the end of the buffer. A caller that compiles an attacker-controlled regular expression on a 32-bit perl build triggers a heap buffer overflow at compile time.

CVE-2026-13221 (2026-07-13)

Perl versions through 5.43.9 produce silently incorrect regular expression matches when an alternation of more than 65535 fixed string branches is compiled into a trie in Perl_study_chunk. When such branches are combined into a trie, the delta between the first branch and the shared tail is stored in a 16-bit field. A branch count above 65535 overflows the field, and the trie's match decision table is truncated with no warning or error. A pattern of this shape produces false positive matches (matching strings it should not) and false negative matches (failing to match strings it should). When such a pattern gates an access or filtering decision, the result is wrong.

NAME

Encode::JP - Japanese Encodings

SYNOPSIS

use Encode qw/encode decode/; 
$euc_jp = encode("euc-jp", $utf8);   # loads Encode::JP implicitly
$utf8   = decode("euc-jp", $euc_jp); # ditto

ABSTRACT

This module implements Japanese charset encodings. Encodings supported are as follows.

Canonical   Alias		Description
--------------------------------------------------------------------
euc-jp      /\beuc.*jp$/i	EUC (Extended Unix Character)
            /\bjp.*euc/i   
        /\bujis$/i
shiftjis    /\bshift.*jis$/i	Shift JIS (aka MS Kanji)
        /\bsjis$/i
7bit-jis    /\bjis$/i		7bit JIS
iso-2022-jp			ISO-2022-JP                  [RFC1468]
              = 7bit JIS with all Halfwidth Kana 
                converted to Fullwidth
iso-2022-jp-1			ISO-2022-JP-1                [RFC2237]
                              = ISO-2022-JP with JIS X 0212-1990
                support.  See below
MacJapanese	                Shift JIS + Apple vendor mappings
cp932       /\bwindows-31j$/i Code Page 932
                              = Shift JIS + MS/IBM vendor mappings
jis0201-raw                   JIS0201, raw format
jis0208-raw                   JIS0208, raw format
jis0212-raw                   JIS0212, raw format
--------------------------------------------------------------------

DESCRIPTION

To find out how to use this module in detail, see Encode.

Note on ISO-2022-JP(-1)?

ISO-2022-JP-1 (RFC2237) is a superset of ISO-2022-JP (RFC1468) which adds support for JIS X 0212-1990. That means you can use the same code to decode to utf8 but not vice versa.

$utf8 = decode('iso-2022-jp-1', $stream);

and

$utf8 = decode('iso-2022-jp',   $stream);

yield the same result but

$with_0212 = encode('iso-2022-jp-1', $utf8);

is now different from

$without_0212 = encode('iso-2022-jp', $utf8 );

In the latter case, characters that map to 0212 are first converted to U+3013 (0xA2AE in EUC-JP; a white square also known as 'Tofu' or 'geta mark') then fed to the decoding engine. U+FFFD is not used, in order to preserve text layout as much as possible.

BUGS

The ASCII region (0x00-0x7f) is preserved for all encodings, even though this conflicts with mappings by the Unicode Consortium.

SEE ALSO

Encode