CVE-2026-19082: TONYC Imager · Out-of-bounds Read
Affects TONYC ImagerSource CVE Database V5
Not known to be exploited · CVSS 7.5 High : upgrade to 1.034 soon.
Data as of 5 Nov 2026, 23:24 UTC
- EPSS
- 0.3% chance of exploitation in 30 days – higher than 31% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
- Patch
- Available – fixed in 1.034
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:NExploitation evidence
Disclosed: evidence found.
CVE published 7 Aug 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponized: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 6 Nov 2026.
What to do
Upgrade TONYC Imager to 1.034.
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| TONYCImager | Affected
| Fixed in
|
GitHubImagerpkg:github/ImagerOther threats | Affected
| Fixed in
|
Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.
AI-suggested
Users should upgrade to Imager version 1.034 or later when available, as the issue is fixed by upgrading. Until then, avoid processing untrusted images with vulnerable versions of Imager.
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.
References
- github.com/tonycoz/imager/security/advisories/GHSA-hx46-55wp-hv6m (opens in a new tab)
- github.com/tonycoz/imager/commit/24bde0427a113264d53f45a9c29ae756d84c82fe.patch (opens in a new tab)
- metacpan.org/release/TONYC/Imager-1.034/changes (opens in a new tab)
- openwall.com/lists/oss-security/2026/08/07/6 (opens in a new tab)