CVE-2026-107391: 
JavaScript vulnerability analysis and mitigation

CVE-2026-107391 is a Denial of Service vulnerability in the music-metadata npm package (by Borewit) caused by a synchronous infinite loop in the MP4 stsd sample-description parser. A regression introduced after version 11.14.0 on the public master branch allows a crafted MP4 file with a zero-sized sample entry and an attacker-controlled entry_count to block the Node.js event loop indefinitely and exhaust process memory. The vulnerability affects development revisions of music-metadata after 11.14.0 and before 11.16.0; the 11.14.0 npm release and all earlier releases are not affected. It carries a CVSS v3.1 base score of 7.5 (High) per Feedly/NVD, and 6.2 (Moderate) per the GitHub Advisory Database (Github Advisory, Security Advisory). The vulnerability was reported by researcher zikk090, published to the GitHub Advisory Database on October 8, 2026, and fixed in version 11.16.0 released September 22, 2026 (v11.16.0 Release).

The root cause is classified as CWE-400 (Uncontrolled Resource Consumption) and CWE-835 (Loop with Unreachable Exit Condition). The regression was introduced by commit d2a7d6f (PR #2693, merged 2026-08-03), which changed the cursor advance in StsdAtom.get() from off += size to off += size - 4 to fix a separate offset bug, but omitted a guard for size < 4. When size == 0, the net per-iteration advance is 4 + (0 - 4) = 0, so the loop cursor never moves; combined with an attacker-controlled entry_count up to 0xFFFFFFFF, the loop runs indefinitely, re-reading the same bytes and growing the table array without bound (Security Advisory). Because StsdAtom.get is invoked synchronously within strtok3's tokenizer with no await point inside the loop, the entire Node.js event loop is blocked — not merely slowed. The attack requires only that the target application passes attacker-supplied MP4-family data to any of parseBuffer, parseFile, parseStream, parseBlob, or parseWebStream (Github Advisory).

Successful exploitation causes a complete availability loss for the affected Node.js process: the event loop is blocked at ~100% CPU and the unbounded table.push() growth exhausts memory until the process is killed externally or crashes. Any application that processes user-uploaded or untrusted audio/video files for metadata — including media libraries, upload pipelines, and transcoding services — is at risk. There is no confidentiality or integrity impact; the vulnerability is purely a Denial of Service condition that can be triggered by a single 48-byte crafted file with no authentication required (Security Advisory).

A public proof-of-concept (PoC) is available within the GitHub Security Advisory itself, demonstrating that a 48-byte crafted MP4 buffer is sufficient to hang the Node.js process (Security Advisory). No authentication or user interaction is required, and attack complexity is low. There is no evidence of in-the-wild exploitation at this time, and the vulnerability was disclosed and patched before the affected code shipped in any npm release (the regression existed only on the master branch, not in any published npm version). The EPSS score is approximately 0.13–0.27% (low probability of near-term exploitation), and the vulnerability is not listed in the CISA KEV catalog (Github Advisory).

1. Identify a target: Find a Node.js application that uses a music-metadata version containing the master-branch regression (post-11.14.0, pre-11.16.0 npm release) and accepts user-supplied MP4-family files for metadata parsing via parseBuffer, parseFile, parseStream, parseBlob, or parseWebStream.
2. Craft the malicious MP4 file: Construct a 48-byte MP4 file consisting of a 16-byte ftyp box (brand M4A) and a 32-byte stsd box with entry_count = 0xFFFFFFFF and a single sample entry whose size field is 0. The hex payload is: 00000010667479704d34412000000000000000207374736400000000ffffffff000000006d7034610000000000000001 (SHA-256: 69ee80747d0a7eda3a0d02f7270d6375c8e7f5ca2231a48be558c2e01c02dd80).
3. Submit the file to the target: Upload or send the crafted file to any endpoint that triggers a music-metadata parse call (e.g., a media upload API, a metadata extraction service).
4. Trigger the infinite loop: The parser's StsdAtom.get() enters the for loop, reads size = 0, computes a net cursor advance of zero, and loops indefinitely — blocking the Node.js event loop at ~100% CPU and growing memory until the process is killed or crashes, denying service to all users of the application (Security Advisory).

• Process Behavior: Node.js process consuming ~100% CPU continuously without completing a parse request; process memory growing unboundedly until OOM kill.
• Logs: Application logs showing a parse request for an MP4/M4A file that never completes or times out; absence of a parse completion or error log entry following an upload event.
• Network: Inbound upload of a very small MP4-family file (≤48 bytes) to a media metadata parsing endpoint; the file's hex content matching 00000010667479704d34412000000000000000207374736400000000ffffffff000000006d7034610000000000000001.
• File System: Presence of a suspicious ≤48-byte .mp4 or .m4a file with SHA-256 69ee80747d0a7eda3a0d02f7270d6375c8e7f5ca2231a48be558c2e01c02dd80 in upload or temp directories (Security Advisory).

The primary remediation is to upgrade music-metadata to version 11.16.0 or later, which validates sample entry sizes and atom boundaries before entering the parse loop, rejecting entries with size < 16 or size > end - off (v11.16.0 Release, Fix PR). Note that only applications running code from the master branch between commits d2a7d6f and 90a7d52 are affected — the 11.14.0 npm release and all earlier published npm versions are not vulnerable. As a temporary workaround if immediate patching is not possible, implement file size limits and request timeouts for MP4 parsing operations, and validate MP4 file structure before passing data to music-metadata (Github Advisory).

The vulnerability was responsibly disclosed by researcher zikk090 before the affected code shipped in any npm release, which the advisory explicitly notes as proactive reporting. The maintainer (Borewit) responded promptly, merging the fix via PR #2734 on September 22, 2026, and releasing version 11.16.0 the same day. The advisory draws a parallel to a prior similar vulnerability in the same project (GHSA-v6c2-xwv6-8xf7 / CVE-2026-32256, an ASF parser infinite loop fixed in 11.12.1), suggesting a pattern of parser input validation issues being actively addressed by the maintainer (Security Advisory, v11.16.0 Release).