Export limit exceeded: 374338 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (6 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-19082 | 1 Tonyc | 1 Imager | 2026-08-07 | 7.5 High |
| 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-14454 | 1 Tonyc | 1 Imager | 2026-07-09 | 9.8 Critical |
| 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-13708 | 1 Tonyc | 1 Imager::file::jpeg | 2026-07-06 | 7.5 High |
| 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-13705 | 1 Tonyc | 1 Imager | 2026-07-06 | 7.1 High |
| 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-8454 | 1 Tonyc | 2 Imager, Imager\ | 2026-05-18 | 5.3 Medium |
| Imager::File::GIF versions through 1.002 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-8669 | 1 Tonyc | 1 Imager | 2026-05-15 | 6.5 Medium |
| 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. | ||||
Page 1 of 1.