CVE-2026-107392

In the public development revision introduced after 11.14.0 of music-metadata, a development-branch regression in the MP4 stsd sample-description parser allows an attacker-controlled sample-entry size of zero to prevent the StsdAtom.get cursor from advancing while an attacker-controlled entry_count keeps the synchronous loop running. A crafted MP4-family input can block the Node.js event loop and grow the sample-description table until the process is terminated or exhausts memory. The vulnerable change was present on the public master branch but was not included in music-metadata 11.14.0 or any earlier npm release, and version 11.16.0 contains the fix.

In music-metadata prior to 11.16.0, the MP4 parser accepts an attacker-controlled 64-bit extended atom size, converts it to a JavaScript Number, and uses the resulting payload length for atom-specific readToken calls before proving that the atom fits within its parent or the available input. A tiny MP4-family file can route an oversized length into payload parsing for atoms including mvhd, stsd, stsz, and date, causing a large allocation attempt or process failure before end-of-input validation. Applications that parse untrusted MP4-family media can therefore be denied service.

In music-metadata prior to 11.16.0, the Matroska and WebM EBML parser decodes an attacker-controlled VINT element length and uses it for string-token or Uint8Array allocation before confirming that the leaf fits within its parent or available input. Crafted WebM, MKV, or MKA inputs can cause disproportionate allocations, out-of-memory denial of service, or, for a demonstrated parseFile path on Node.js 26.7.0, an uncatchable V8 fatal abort. The exact failure mode depends on the tokenizer, parser API, and runtime, but the affected leaf-length validation flaw is shared and has availability impact only.

In music-metadata prior to 11.16.0, the ID3v2 parser trusts the syncsafe tag-size field and allocates the complete tag body before checking whether the input contains the declared bytes. A truncated file containing only an ID3v2 header can request an allocation approaching 268 MiB; the allocation succeeds, the subsequent read reaches end of stream, the EndOfStreamError is caught internally, and the caller receives a normal metadata object.

Prior to version 11.16.0, the APEv2 parser in the music-metadata library reads an attacker-controlled tag-item size and allocates a Uint8Array for a binary item before verifying that the declared size fits in the remaining data. A small crafted APE file can trigger a disproportionate allocation, and repeated or concurrent parsing can exhaust process memory. This issue is fixed in version 11.16.0.