music-metadata CVE-2026-107391

Exploitable only when the application parses attacker-supplied MP4-family input through music-metadata AND is running the unreleased master-branch code containing commit d2a7d6f (the off += size - 4 change) up to but not including the 11.16.0 fix - no published npm release (11.14.0 or earlier) is vulnerable, which is the dominant limiting factor. No authentication or user interaction is required at the parser level (PR:N/UI:N): any of parseBuffer, parseFile, parseStream, parseBlob, or parseWebStream will trigger it on a crafted MP4 declaring a large entry_count and a first sample-entry size field of 0. The practical limiter for defenders is therefore install method (git/master vs npm) rather than configuration.

This is a CWE-400 uncontrolled-resource-consumption (DoS) flaw with no confidentiality or integrity impact (C:N/I:N/A:H). The single most important risk signal is NOT the CVSS score but the release status: per the GHSA advisory and the reporter's own note, the vulnerable off += size - 4 change existed ONLY on the public master branch (introduced by commit d2a7d6f after PR #2693) and was NEVER shipped in music-metadata 11.14.0 or any earlier npm release; 11.16.0 is the fix. Consequently, any consumer installing from npm is unaffected, and real-world exploitable exposure is limited to the rare case of installing directly from git/master between the regression and the fix. No EPSS score was provided and the CVE is not in CISA KEV, so there is no evidence of active exploitation; a working crafted reproducer (a 48-byte MP4 buffer) is embedded in the advisory and regression test, so a functional proof-of-concept is public. CONFLICTING SIGNAL worth flagging: NVD scored this AV:L (local, score 6.2), but the advisory explicitly describes the trigger as user-uploaded media processed by services via parseBuffer/parseFile/parseStream/parseBlob/parseWebStream - that is network-delivered attacker data, which argues for AV:N and a higher (~7.5) base score. Verify the attack vector against your deployment: if the parser handles network-uploaded files, treat it as remotely reachable. Net assessment: genuine, easily triggered DoS in code terms, but LOW real-world priority because no released package version is affected.

An attacker uploads a tiny (48-byte) crafted MP4-family file to a Node.js service that extracts audio/video metadata using music-metadata built from the master branch. The file declares a huge stsd entry_count and a first sample-entry size of 0, so the synchronous StsdAtom.get loop never advances its cursor, pinning one CPU at ~100% and blocking the entire Node event loop until the process is killed or memory is exhausted. A public proof-of-concept buffer exists in the GHSA advisory and the project's regression test.