music-metadata

## Summary `music-metadata` 11.15.0 is vulnerable to uncontrolled memory allocation in the APEv2 parser. The parser reads the size of an APEv2 tag item from the input file and uses that value to allocate memory before checking whether the file actually contains that many bytes. A small crafted `.ape` file can declare a very large binary tag item, such as cover art, and force the parser to allocate a large buffer. This issue is specific to APEv2 parsing and is separate from the ID3v2, MP4, and EBML advisories. ## Affected component - `lib/apev2/APEv2Token.ts` - `lib/apev2/APEv2Parser.ts`

CVE: CVE-2026-107387

## Summary The Matroska/WebM EBML parser decodes attacker-controlled variable-length integer (VINT) element lengths without first validating that the declared element fits within its enclosing container or the available input. Leaf lengths are then used directly for string-token and `Uint8Array` allocations. A very small crafted `.webm`, `.mkv`, or `.mka` file can therefore cause a disproportionately large allocation, an out-of-memory denial of service, or—in one demonstrated `parseFile` case—an uncatchable V8 fatal abort. ## Impact Applications that parse untrusted Matroska/WebM media can

CVE: CVE-2026-107389

## Summary `DsfParser.parseChunks` skips an unrecognised chunk's payload with an **un-awaited** call: ```js this.tokenizer.ignore(Number(chunkHeader.size) - ChunkHeader.len); // lib/dsf/DsfParser.js:51 — no await ``` `ChunkHeader.len` is 12. A crafted `.dsf` chunk with `id != 'fmt '` and `size` in `0..11` makes the argument negative; strtok3 (≥ 10.3.5) throws `RangeError` on a negative `ignore`. Because the call is fire-and-forget, the rejection is **detached from the `parseBuffer()` promise chain** → unhandled rejection → Node's default (≥ 15) **crashes the process** — **after** `parseBuffe

CVE: CVE-2026-107392

### Summary `StsdAtom.get()` in `lib/mp4/AtomToken.ts` parses an MP4 `stsd` (sample description) box's entry table by advancing a cursor with `off += size - 4`, where `size` is a 32-bit, attacker-controlled per-entry length read straight from the file. When `size == 0`, that advance is `0`, so a file declaring a huge `entry_count` and a first entry `size` of `0` spins forever: same bytes read every iteration, no progress, no exit. Because `StsdAtom.get` runs *synchronously* inside `strtok3`'s tokenizer, this doesn't just fail slowly — it blocks the Node.js event loop entirely for the whole pr

CVE: CVE-2026-107391

### Summary The ID3v2 parser in music-metadata trusts the tag size field without validation and allocates the full requested buffer before reading. A specially crafted MP3 file with a truncated ID3v2 tag can force allocation of up to 268 MB from a 10-byte file, causing server memory exhaustion. This vulnerability affects all parsers that support ID3v2 tags (MP3, FLAC, DSF, Musepack) and succeeds silently—callers don't see an error. --- ### Details **Vulnerable Code Path:** - `lib/id3v2/ID3v2Token.ts:108` - Syncsafe size read without validation - `lib/id3v2/ID3v2Parser.ts:122` - Full tag b

CVE: CVE-2026-107388

# Summary music-metadata's ASF parser (`parseExtensionObject()` in `lib/asf/AsfParser.ts:112-158`) enters an infinite loop when a sub-object inside the ASF Header Extension Object has `objectSize = 0`. ## Root Cause When objectSize is 0: 1. `remaining = 0 - 24 = -24` 2. `tokenizer.ignore(-24)` moves the read position backward by 24 bytes 3. `extensionSize -= 0` (loop counter never decreases) 4. `while (extensionSize > 0)` never exits 5. The same 24-byte header is re-read infinitely This is the same pattern as CVE-2026-31808 (GHSA-5v7r-6r5c-r473) in file-type — strtok3's `AbstractTokenizer.

CVE: CVE-2026-32256