CVE-2026-107391 in music-metadata
Summary
by MITRE • 10/08/2026
music-metadata is a metadata parser for audio and video media files. In the public development revision introduced after 11.14.0, 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. This issue is fixed in version 11.16.0.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/09/2026
The vulnerability identified within the music-metadata library represents a critical denial of service condition arising from insufficient input validation during the parsing of MP4 container files, specifically targeting the sample description atom known as stsd. As a widely used Node.js module for extracting metadata from audio and video media files, this component is frequently employed in server-side applications to process user-uploaded content or analyze local media libraries. The core technical flaw resides within the parser logic responsible for handling MP4 family formats, where the implementation fails to enforce minimum bounds on critical structural fields defined by the ISO Base Media File Format specification. Specifically, when processing the sample-entry size field within the stsd atom, the library does not verify that this value is greater than zero before proceeding with subsequent parsing operations. This oversight allows an attacker to craft a malicious MP4 file containing a sample entry with a size of exactly zero, which triggers a regression in the synchronous loop logic designed to iterate through the entries listed in the container's header.
The operational impact of this flaw is severe for any application relying on music-metadata for processing untrusted media files. Because the parser utilizes a synchronous loop that relies on the sample-entry size to advance its internal cursor position, a zero-size entry causes the cursor to remain static while the iteration counter continues to increment based on the attacker-controlled entry_count field found in the atom header. This discrepancy creates an infinite or near-infinite loop within the Node.js event loop thread. Since JavaScript execution is single-threaded and blocking by nature when synchronous code runs, this behavior effectively freezes the entire application process. The parser attempts to continuously read from a zero-length sample description table, leading to rapid memory exhaustion as internal data structures grow without bound until the operating system terminates the process due to out-of-memory conditions or resource limits are reached. This constitutes a classic denial of service attack vector that can be exploited remotely if an attacker can induce a server to parse their crafted file.
From a classification perspective, this vulnerability aligns with CWE-400, which describes uncontrolled resource consumption, as the application fails to limit the resources consumed during input processing. Furthermore, it relates closely to CWE-617, reachable assertion failure or infinite loop due to logic errors in parsing external data structures. In terms of adversarial tactics, this exploit maps directly to MITRE ATT&CK technique T1499, Endpoint Denial of Service, specifically under the sub-category of resource exhaustion via application-level loops. The vulnerability highlights the risks associated with synchronous file processing in Node.js environments when dealing with potentially malicious inputs that abuse parsing logic rather than relying on buffer overflows or injection attacks.
Mitigation strategies must prioritize immediate version upgrades and defensive coding practices. The primary remediation is to upgrade the music-metadata dependency to version 11.16.0 or later, where the developers have implemented checks to ensure sample-entry sizes are valid before processing them within the loop structure. For applications that cannot immediately update their dependencies due to compatibility constraints, it is advisable to implement a sandboxing layer around file parsing operations. This can include setting strict timeouts on synchronous execution blocks using Node.js timers or running the parser in a separate worker thread with memory limits enforced by the operating system. Additionally, input validation at the ingestion point should be strengthened to reject MP4 files that exhibit structural anomalies such as zero-length sample entries before they reach the parsing engine. Regular security audits of media processing libraries are essential to identify similar regressions where development branch changes introduce logic errors into production code paths.