Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-08-07T18:17:11.363Z",
  "pubdate": "2026-08-07T18:17:11.363Z",
  "executiveSummary": "A heap over-read vulnerability exists in the Imager module for Perl, specifically within the copy_string_tags() function. The vulnerability arises from improper handling of zero-count ASCII EXIF entries, which allows an attacker to supply a specially crafted image that triggers an out-of-bounds memory read using strlen().\nThe impact of this vulnerability includes the potential exposure of adjacent heap bytes. When an application calls Imager->read() on a malicious image, the resulting exif_* tags may contain sensitive data residing on the heap instead of an empty string, leading to potential information disclosure.\nThe affected product is Imager for Perl, with vulnerable versions ranging from 0.45_02 before 1.034. Additionally, the separate Imager::File::WEBP distribution is impacted and requires upgrading the core Imager library for remediation.\nAttacker capabilities are limited to information disclosure via manipulated image files. Exploitation requires an attacker to supply a crafted image containing a zero-count ASCII EXIF entry, which is then processed by a vulnerable caller invoking Imager->read().",
  "technicalDetails": "The vulnerability is rooted in the copy_string_tags() function, which computes an ASCII EXIF tag's length by subtracting one from the entry size, expressed mathematically as entry->size - 1, intended to strip the trailing NUL terminator.\nWhen a zero-count ASCII entry is encountered, entry->size is set to 0. Consequently, the derived length calculation results in -1.\nThis negative value is subsequently passed to i_tags_add(), where it is interpreted as a request to invoke the standard C library function strlen().\nBecause strlen() scans memory sequentially until a NUL byte is encountered, it reads past the bounds of the original EXIF entry buffer and into adjacent heap memory.\nThe out-of-bounds bytes are then copied into the resulting tag string, exposing raw heap contents to the caller.\nThe attack flow begins when an attacker crafts a malicious image file containing a zero-count ASCII EXIF entry. This image file is then provided to an application utilizing Imager for Perl.\nThe vulnerable execution path is reached via JPEG processing through im_decode_exif(), as well as via the separate Imager::File::WEBP distribution.\nAny caller executing Imager->read() on the attacker-supplied image triggers the vulnerable parsing logic.\nUpon successful processing, the application receives an exif_* tag holding adjacent heap bytes instead of an expected empty string, leaking potentially sensitive heap data back to the caller or log mechanisms.\nAffected versions of Imager for Perl span from 0.45_02 prior to version 1.034. The vulnerability does not require authentication or elevated privileges, provided the application processes untrusted image input over network or local interfaces."
}