There are 11 open security issues in trixie.
11 issues left for the package maintainer to handle:
- CVE-2026-8669:
(needs triaging)
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:
(needs triaging)
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-13708:
(needs triaging)
Imager::File::JPEG versions before 1.003 for Perl leak heap memory when reading a JPEG with repeated APP13 markers in i_readjpeg_wiol. i_readjpeg_wiol walks the marker list libjpeg returns and, for each APP13 marker, allocates a new buffer with *iptc_itext = mymalloc(...) and overwrites the previous pointer without freeing it. Only the final payload is later turned into a Perl scalar and freed, so a JPEG with N such markers leaks the first N-1 payloads on every read. In a long-lived process, such as an upload or thumbnailing service, repeated reads accumulate these leaks and exhaust available memory, a denial of service. The same handler ships bundled in the Imager distribution, where versions before 1.032 are affected and the fix ships in 1.032.
- CVE-2026-14454:
(needs triaging)
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.
- CVE-2026-19082:
(needs triaging)
Imager versions from 0.45_02 before 1.034 for Perl may expose adjacent heap bytes via strlen() over-read from zero-count ASCII EXIF entries in copy_string_tags. copy_string_tags() computes an ASCII EXIF tag's length as `entry->size - 1` to strip the trailing NUL. A zero-count ASCII entry sets `entry->size` to 0, and the derived length reaches i_tags_add() as -1, which is interpreted as a request to call strlen(), scanning past the entry to the next NUL and copying those bytes into the tag. JPEG reaches this path via im_decode_exif(), as does the separate Imager::File::WEBP distribution, which is fixed by upgrading Imager. Any caller of Imager->read() on an attacker-supplied image with such an entry may receive an exif_* tag holding adjacent heap bytes instead of an empty string.
- CVE-2026-73638:
(needs triaging)
Imager versions from 0.45_02 before 1.035 for Perl read outside the EXIF block via unchecked start offsets in tiff_load_ifd. tiff_load_ifd() validates an IFD entry's data by checking that `entry->offset + entry->size` stays within the EXIF block, and never checks the start offset itself. Where that sum is not the real end of the data, the check passes with the entry starting outside the block. Through 1.032 `entry->offset` is a plain int, so on the usual two's-complement implementations an offset with the high bit set converts to negative and the sum can land back inside the block. From 1.033 the field is a size_t and the addition wraps only where size_t is 32 bits. The IFD's own start offset is checked the same way and wraps where unsigned long is 32 bits, which includes 64-bit Windows. Any caller of Imager->read() on an attacker-supplied image may receive EXIF tags holding bytes from outside the block, or crash the process.
- CVE-2026-73639:
(needs triaging)
Imager::File::PNG versions from 1.003 before 1.004 for Perl write past the end of the row buffer reading a PNG with a tRNS transparency chunk in read_direct8. With a tRNS chunk, read_direct8() adds an alpha channel to the image it creates but still sizes the row buffer from the original channel count. libpng expands the transparency into that extra channel, so png_read_row() fills one channel more than the buffer holds, at one byte per sample, and writes width bytes past the end of the allocation. Palette images go to read_paletted() and 16-bit images to read_direct16(), which sizes its buffer from png_get_rowbytes() and allocates enough for the expanded row. The same reader ships bundled in the Imager distribution. Reading an attacker-supplied PNG through Imager->read() corrupts the heap, which can crash the process.
- CVE-2026-93018:
(needs triaging)
Imager versions before 1.036 for Perl disclose uninitialised heap memory reading a paletted image with pixel indexes past its colour map in i_gpix_p and i_glin_p. The palette is allocated uninitialised, and only the entries a reader adds count as populated. The TGA reader stores pixel indexes without checking them against the colour map. i_gpix_p() rejects only an index greater than the count, so an index equal to it reads the first unpopulated entry, and getpixel() returns it. i_glin_p() skips any index at or beyond the count without writing that pixel to the caller's buffer. The palette-to-RGB conversion reads each row through an uninitialised buffer, so those pixels of the converted image hold prior heap contents. Reading an attacker-supplied image through Imager->read() and then fetching its pixels or converting it to RGB discloses process heap memory.
- CVE-2026-93019:
(needs triaging)
Imager versions before 1.036 for Perl exit the process reading a TGA with a colour map length of 32768 or more in tga_palette_read. The reader unpacks the two-byte colour map length into a signed short, so a length of 32768 or more becomes negative. tga_palette_read() casts that value to size_t and asks mymalloc() for a size near SIZE_MAX. The allocation fails and Imager's allocator calls exit(3). Reading an attacker-supplied file through Imager->read() triggers an uncatchable exit.
- CVE-2026-102504:
(needs triaging)
Imager versions before 1.037 for Perl exit the process reading a raw image with an out-of-range raw_datachannels value in i_readraw_wiol. Nothing range-checks raw_datachannels. The line buffer is sized as the image width times the channel count with no overflow check, so a negative or very large count requests an excessive allocation. When it fails, Imager's allocator calls exit(3). Passing an untrusted raw_datachannels value to Imager->read() triggers an uncatchable exit.
- CVE-2026-102505:
(needs triaging)
Imager versions before 1.037 for Perl overflow a heap buffer fetching float samples from a paletted image in i_gsampf_fp. For a paletted image, getsamples() with type "float" allocates a buffer of one sample per pixel and fetches every requested channel of each pixel into it. Requesting more than one channel writes past its end. An attacker-supplied image controls the overflowing bytes through its palette.
You can find information about how to handle these issues in the security team's documentation.
![[bug history graph]](https://qa.debian.org/data/bts/graphs/libi/libimager-perl.png){kind=link}