CVE-2026-107388: 
JavaScript vulnerability analysis and mitigation

CVE-2026-107388 is a memory exhaustion denial-of-service vulnerability in the music-metadata npm package (by Borewit), a widely used metadata parser for audio and video files. The ID3v2 parser trusts the syncsafe tag-size field without validation and allocates the full declared buffer before checking whether the input actually contains the claimed bytes. A 10-byte truncated file with a maximally-valued syncsafe size field can trigger an allocation of up to 268 MB, with the resulting EndOfStreamError silently swallowed so the caller receives a normal metadata object. All versions up to and including 11.12.3 are affected; the fix is available in version 11.16.0. The CVSS v3.1 base score is 6.2 (Moderate) per the GitHub Advisory, with an alternate NVD score of 5.5 (Medium) (Github Advisory, Security Advisory).

The root cause is classified as CWE-789 (Memory Allocation with Excessive Size Value): the parser reads a syncsafe integer from the ID3v2 header at lib/id3v2/ID3v2Token.ts:108 and immediately allocates a buffer of that size in lib/id3v2/ID3v2Parser.ts:122 without verifying that the declared size is within the remaining file size or any reasonable bound. The maximum syncsafe value (0x7F7F7F7F) decodes to 268,435,455 bytes (~268 MB), achievable with just 10 bytes of input — a memory amplification ratio of approximately 26.8 million to one. The subsequent stream read hits EOF, the EndOfStreamError is caught internally and suppressed, and the caller receives an empty but valid metadata object, making the attack entirely silent. Affected parsers include MP3, FLAC, DSF, and Musepack — any format that routes through the ID3v2 code path (Security Advisory, Fix Commit).

The sole impact is availability: successful exploitation causes uncontrolled memory allocation of up to 268 MB per malicious file parse, with no effect on confidentiality or data integrity. In a service that accepts user-uploaded audio files, an attacker uploading 10 such files simultaneously could force ~2.68 GB of memory allocation, potentially triggering out-of-memory kills and crashing worker processes. Distributed attacks with 100 concurrent uploads could exhaust ~26.8 GB of server memory, causing sustained denial of service. Affected services include any Node.js application using music-metadata for file upload processing, such as music streaming platforms, podcast hosts, media servers, and audio processing pipelines (Security Advisory).

A proof-of-concept exploit is publicly available in the GitHub Security Advisory, consisting of a 10-byte JavaScript Uint8Array that can be passed directly to parseBuffer() to trigger the vulnerability — no authentication or special privileges are required (Security Advisory). The EPSS score is approximately 0.13–0.14% (3rd percentile), indicating low current exploitation probability. There is no evidence of in-the-wild exploitation or threat actor attribution at this time, and the vulnerability is not listed in the CISA KEV catalog. The NVD SSVC assessment classifies exploitation status as "poc" and the attack as non-automatable (Github Advisory).

1. Identify a target service: Locate a web application or API endpoint that accepts audio file uploads (MP3, FLAC, DSF, or Musepack) and uses music-metadata versions ≤ 11.12.3 for metadata parsing.
2. Craft the malicious file: Construct a 10-byte truncated ID3v2 header with the syncsafe size field set to its maximum value:

const maliciousFile = Uint8Array.from([
  0x49, 0x44, 0x33, // "ID3" identifier
  0x04, 0x00,       // Version 2.4.0
  0x00,             // Flags
  0x7f, 0x7f, 0x7f, 0x7f // Syncsafe max size: 268,435,455 bytes
]);

3. Submit the file to the target: Upload the 10-byte file to the service's audio upload endpoint with MIME type audio/mpeg (or another ID3v2-supporting type such as audio/flac).
4. Trigger memory allocation: The parser reads the syncsafe size field, allocates a ~268 MB buffer, hits EOF on the stream read, silently swallows the EndOfStreamError, and returns a normal metadata object — leaving 268 MB allocated until garbage collection.
5. Amplify the attack: Repeat or parallelize uploads (e.g., 10 concurrent requests = ~2.68 GB allocated) to exhaust server memory, trigger OOM kills, and cause denial of service (Security Advisory).

• Network: Repeated upload requests to audio file ingestion endpoints with extremely small file sizes (≤ 10–20 bytes) but valid audio/mpeg, audio/flac, or similar MIME types; high request rates to metadata parsing endpoints from a single IP or distributed sources.
• File System: Presence of 10-byte files with the magic bytes 49 44 33 ("ID3") followed by 7f 7f 7f 7f in upload staging directories or temporary processing folders.
• Process/Memory: Sudden spikes in Node.js process external memory (V8 external heap) to hundreds of megabytes or gigabytes without corresponding large file uploads; OOM kill events (SIGKILL) targeting Node.js worker processes in application logs.
• Logs: Application logs showing music-metadata parseBuffer() calls completing successfully (no error thrown) for files reported as only a few bytes in size; absence of expected metadata fields (format, common, native all empty {}) in parse results for uploaded audio files (Security Advisory).

The primary remediation is to upgrade music-metadata to version 11.16.0 or later, which validates the declared ID3v2 tag size against the remaining file size before allocation and throws an Id3v2ContentError if the declared size exceeds available bytes (Release v11.16.0, Fix Commit). As a workaround prior to patching, implement input validation to reject audio files below a minimum reasonable size threshold before passing them to the parser, and enforce per-request memory limits or process isolation for metadata parsing workers. Additionally, consider rate-limiting file upload endpoints and restricting accepted file sources to trusted users where feasible (Security Advisory).

The vulnerability was reported by researcher Zwique and addressed by maintainer Borewit, who merged the fix (PR #2743) on September 22, 2026, and published the security advisory on September 23, 2026. The v11.16.0 release bundled this fix alongside several other allocation-validation security fixes for MP4, APEv2, and EBML parsers, suggesting a broader security audit of the library's parser components (Release v11.16.0, Fix PR). No significant broader media coverage or notable social media discussion has been identified beyond the GitHub advisory ecosystem.