/ 
Imager-1.027
⭐ Starred 27 / Imager::File::JPEG
Security Advisories (3)
CVE-2026-8669 (2026-05-15)

Imager versions through 1.030 for Perl allow a heap out of bounds (OOB) write on crafted multi-frame GIF files. Imager::File::GIF's i_readgif_multi_low allocates a single per-row buffer GifRow sized for the GIF's global screen width 'SWidth' and reuses it across every image in the file. The page-match branch validates Image.Width + Image.Left > SWidth before each DGifGetLine write, but the parallel skip-image branch at imgif.c:790-805 calls DGifGetLine(GifFile, GifRow, Width) with no such check.

CVE-2026-13705 (2026-07-06)

Imager versions before 1.032 for Perl have a heap out-of-bounds read in the bundled Imager::File::SGI reader via a 16-bit RLE literal run in read_rgb_16_rle. read_rgb_16_rle guards each literal run with if (count > data_left), but count is a pixel count while every 16-bit sample consumes two bytes. The copy loop reads inp[0] * 256 + inp[1] and advances two bytes per pixel, so a run with data_left / 2 < count <= data_left passes the guard yet consumes 2 * count bytes and reads past the end of the buffer. The 8-bit path is unaffected because there one pixel is one byte. Reading a crafted SGI image through Imager->read triggers the over-read before the parser rejects the malformed image, which can crash the process.

CVE-2026-14454 (2026-07-08)

Imager versions before 1.033 for Perl treat unsigned EXIF IFD entry counts as signed. Imager mishandled large EXIF IFD entry count values, treating them as negative numbers. This could lead to an attempt to allocate a block nearly the size of the address space, which fails and kills the process. An attacker could craft an image with EXIF data that terminates a worker process.

NAME

Imager::File::JPEG - read and write JPEG files

SYNOPSIS

use Imager;

my $img = Imager->new;
$img->read(file=>"foo.jpg")
  or die $img->errstr;

$img->write(file => "foo.jpg")
  or die $img->errstr;

my $version = Imager::File::JPEG->libjpeg_version();
if (Imager::File::JPEG->is_turbojpeg) { ... }
if (Imager::File::JPEG->is_mozjpeg) { ... }

if (Imager::File::JPEG->has_arith_coding) { ... }

DESCRIPTION

Imager's JPEG support is documented in Imager::Files.

Besides providing JPEG support, Imager::File::JPEG has the following methods:

libjpeg_version()
Imager::File::JPEG->libjpeg_version();

Returns version information about the variety of libjpeg Imager::File::JPEG was compiled with. This is determined at build time. This includes:

  • The library type, one of libjpeg, libjpeg-turbo or mozjpeg.

  • version followed by the library version number.

  • api followed by the libjpeg API version.

For libjpeg the API and library versions are always equal.

is_turbojpeg()
Imager::File::JPEG->is_turbojpeg();

Returns true if Imager::File::JPEG was built with libjpeg-turbo. Note that mozjpeg is built on top of libjpeg-turbo so this will return true for mozjpeg.

is_mozjpeg()
Imager::File::JPEG->is_mozjpeg();

Returns true if Imager::File::JPEG was built with mozjpeg. Note that mozjpeg doesn't define its own version numbering, so mozjpeg is detected by defines that only mozjpeg currently defines.

has_arith_coding()

Returns true if the libjpeg variant Imager::File::JPEG was built with has both encoding and decoding support for arithmetic coding.

has_encode_arith_coding()

Returns true if the libjpeg variant Imager::File::JPEG was built with has encoding support for arithmetic coding.

has_decode_arith_coding()

Returns true if the libjpeg variant Imager::File::JPEG was built with has decoding support for arithmetic coding.

AUTHOR

Tony Cook <tonyc@cpan.org>

SEE ALSO

Imager, Imager::Files.