Description

ExifReader is a JavaScript Exif information parser. Prior to 4.41.1, ExifReader parses attacker-controlled HEIC or AVIF ISO-BMFF files in getItems() within src/image-header-iso-bmff-iloc.js and trusts iloc itemCount and extentCount values while allocating an extent object for every nested-loop iteration. When offsetSize, lengthSize, baseOffsetSize, and indexSize are zero, the extent fields consume no input bytes and the buffer offset does not advance, but the parser can still allocate up to itemCount multiplied by extentCount objects without an allocation budget. A small malicious iloc box can therefore cause hundreds of megabytes of heap growth or exhaust system memory, terminating a Node.js process and denying service to web, desktop, or mobile applications that parse untrusted images. The zero field widths are valid ISO-BMFF values indicating absent fields, so the vulnerable parser must bound work rather than relying on offset advancement. The issue is fixed in version 4.41.1.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-09-17T16:18:15.790Z",
  "pubdate": "2026-09-17T16:18:15.790Z",
  "executiveSummary": "ExifReader versions prior to 4.41.1 are susceptible to a memory exhaustion vulnerability (Denial of Service) triggered by maliciously crafted HEIC or AVIF image files.\nThe vulnerability arises from improper input validation during the parsing of ISO-BMFF (ISO Base Media File Format) containers, specifically within the iloc (item location) box.\nAn attacker can exploit this by supplying an image with specifically crafted box parameters where field sizes are set to zero, causing the parser to enter an unbounded allocation loop.\nBy manipulating itemCount and extentCount values, an attacker can force the Node.js process to allocate excessive memory, leading to heap exhaustion and system instability.\nThis vulnerability is critical for applications processing untrusted user-uploaded imagery, as it allows for a remote Denial of Service without requiring authentication or specific user privileges.\nImpact is global to the runtime environment, potentially crashing web servers, desktop applications, or mobile platforms utilizing the library.",
  "technicalDetails": "The vulnerability is located in the getItems() function within src/image-header-iso-bmff-iloc.js. The root cause is the reliance on trusting itemCount and extentCount values from the ISO-BMFF iloc box without implementing an allocation budget or sanity checks on progress.\nIn the ISO-BMFF specification, fields such as offsetSize, lengthSize, baseOffsetSize, and indexSize define the byte-width of associated metadata. When these values are set to zero, the standard implies the absence of these fields, meaning the parser's internal buffer offset does not advance during iteration.\nThe parser enters a nested loop structure: the outer loop iterates based on itemCount, and the inner loop iterates based on extentCount. For each iteration, the parser performs object allocation to store extent information. Because the offset does not advance when field sizes are zero, the parser can allocate an arbitrary number of objects without consuming or validating input data length.\nAn attacker can craft a minimal iloc box where itemCount and extentCount are set to large values, while field sizes are set to zero. This effectively creates an infinite or near-infinite allocation loop relative to the size of the malicious file. The parser continues to allocate memory on the heap until the Node.js process hits its memory limit and crashes due to OOM (Out of Memory) conditions.\nExploitation does not require authentication or elevated privileges; it only requires that the target system attempts to parse the malicious image file. Since the parser fails to bound the amount of work based on the actual input buffer size, the library is incapable of preventing the exhaustion of the process heap.\nThe attack flow follows these steps: 1) The attacker provides a specially crafted HEIC/AVIF file containing an iloc box with high iteration counts and zero-width fields. 2) The application passes this file to ExifReader for metadata extraction. 3) getItems() commences processing the iloc box. 4) The nested loops iterate, creating extensive heap allocations without consuming source bytes. 5) The heap rapidly expands until the runtime environment terminates the process, resulting in a successful Denial of Service."
}