Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
6 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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 entrycount 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 process. A 48-byte file is enough to hang any service that parses user-uploaded audio/video metadata through parseBuffer, parseFile, parseStream, parseBlob, or parseWebStream. This is currently unreleased — present on the master branch only, not in the latest npm release (11.14.0) or any earlier one. Reporting now, before it ships. Details lib/mp4/AtomToken.ts, StsdAtom.get(): - Introduced by commit d2a7d6f ("fix(mp4): locate…
Recommended action: Upgrade to 11.16.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 The untrusted size is read here: It is later used directly for allocation when parsing binary tag items: The allocation happens before the parser confirms that the declared size fits inside the remaining file data. Impact An application that parses untrusted .ape files with music-metadata may be vulnerable to denial of service through memory exhaustion. The demonstrated payload is only 134 bytes but causes a 128…
Recommended action: Upgrade to 11.16.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 body allocated before reading - lib/id3v2/AbstractID3Parser.ts:22 - Allocation happens before stream validation Root Cause: The ID3v2 parser reads a syncsafe integer representing the tag size (maximum 268,435,455 bytes or 0x0FFFFFFF) and immediately allocates a buffer of that size without checking: 1. If the tag size exceeds the remaining file size 2. If the tag size exceeds a reasonable maximum 3. If the subsequent…
Recommended action: Upgrade to 11.16.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 be denied service. Depending on the input, parser API, and Node.js/V8 version, the demonstrated outcomes include: - a 34-byte input causing an approximately 128 MiB allocation before end-of-input; - a 70-byte input causing a 500 MiB allocation through a binary EBML leaf, with concurrent parses multiplying memory consumption; - a 48-byte file causing an uncatchable V8 fatal abort through parseFile when a leaf…
Recommended action: Upgrade to 11.16.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
DsfParser.parseChunks skips an unrecognised chunk's payload with an un-awaited call: 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 parseBuffer() already resolved, so a caller's try/catch catches nothing and is still taken down. Residual of GHSA-v6c2-xwv6-8xf7: the ASF site was fixed in 11.12.3 (size validation) and strtok3 now throws on negative ignore; the DSF site was never validated, and its missing await escalates that throw into an uncatchable crash. Root cause (lib/dsf/DsfParser.js:34-56) strtok3 AbstractTokenizer.ignore (L78-79): if (length < 0) throw new RangeError('ignore length must be ≥ 0 bytes'); Steps to reproduce repro/ — public API only, Node's default…
Recommended action: Upgrade to 11.15.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.ignore() accepts negative values without validation. Affected Methods - parseFile() — HANGS (FileTokenizer inherits vulnerable ignore()) - parseBuffer() — HANGS (BufferTokenizer inherits vulnerable ignore()) - parseStream() — NOT affected (ReadStreamTokenizer has own ignore() that throws RangeError) Impact A 100-byte crafted .asf file permanently hangs any application using parseFile() or parseBuffer(). music-metadata…
Recommended action: Upgrade to 11.12.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.