CVE-2026-107387: Uncontrolled Memory Allocation (OOM) in music-metadata APEv2 Parser

The NPM package music-metadata is a widely integrated Node.js library designed to parse metadata from audio and video files. It supports a variety of formats, including Monkey's Audio (.ape), which relies on APEv2 tags to store structured metadata. These tags can contain text fields, external links, or binary data payloads such as cover-art images.

Because metadata parsing is commonly integrated into automated file upload pipelines, media servers, and ingestion queues, the parser is exposed to untrusted files provided directly by users. A vulnerability within this processing layer bypasses typical application-level checks, as the payload is parsed programmatically and immediately upon file receipt.

The attack surface is highly accessible because it does not require authentication or application-level privileges. An attacker simply needs to submit a malformed file to any ingestion endpoint that extracts audio metadata, making this a practical mechanism for targeted Denial of Service attacks against host processes.

The technical flaw stems from the parser's trust in metadata header declarations prior to confirming physical stream boundaries. This issue represents a classic implementation of CWE-789 (Memory Allocation with Excessive Size Value). When reading APEv2 structures, the file parser relies on a 32-bit unsigned little-endian integer to determine the size of incoming binary payloads, such as cover-art structures.

In vulnerable versions of music-metadata (< 11.16.0), the library reads this 32-bit length field and immediately invokes the V8 engine's allocator to instantiate a backing Uint8Array. In Node.js, calling new Uint8Array(size) instantly claims physical and virtual memory spaces on the heap.

If the actual input file is truncated (for example, containing only 134 bytes but claiming an image payload of 128 MiB), the subsequent read operations on the input stream inevitably fail, throwing an EndOfStreamError. However, because the Uint8Array allocation occurred prior to this read attempt, the physical heap memory is already reserved. If multiple such requests are processed concurrently, the memory utilization spikes exponentially, exhausting system memory and triggering a process-level Out of Memory (OOM) crash.

The vulnerable file path is located in the APEv2 processing logic, specifically inside lib/apev2/APEv2Parser.ts. The old code performed an unvalidated read sequence:

// VULNERABLE IMPLEMENTATION
// Instantiates the full array directly from the unverified tagItemHeader.size variable
const picData = new Uint8Array(tagItemHeader.size);
await this.tokenizer.readBuffer(picData);

To resolve this vulnerability, commit b3bf52cb6021b046f33ba47583e19ab8f10dd235 introduced two principal mitigation mechanisms: strict boundary validations and a chunked stream reader.

First, the updated parser checks the requested item size against the remaining bytes in the tag block (bytesRemaining) and the total file size (when known from the stream context):

// PATCHED IMPLEMENTATION
const tagItemHeader = await this.tokenizer.readToken<ITagItemHeader>(TagItemHeader);
bytesRemaining -= TagItemHeader.len;
 
if (tagItemHeader.size >= bytesRemaining) {
  throw new ApeContentError(`Invalid tag item size: ${tagItemHeader.size}`);
}
 
if (this.tokenizer.fileInfo.size !== undefined &&
  tagItemHeader.size > this.tokenizer.fileInfo.size - this.tokenizer.position) {
  throw new ApeContentError(`Invalid tag item size: ${tagItemHeader.size}`);
}

Second, to handle streaming inputs where the overall file size cannot be verified upfront (e.g., live network sockets), the library introduced a bounded streaming buffer reader (readTagValue). This method restricts instant allocation sizes to a safe block limit of 64 KiB, allocating subsequent segments incrementally as data packets actually arrive:

private async readTagValue(size: number): Promise<Uint8Array> {
  const chunkSize = 64 * 1024;
  if ((!this.tokenizer.supportsRandomAccess() || this.tokenizer.fileInfo.size === undefined) && size > chunkSize) {
    const chunks: Uint8Array[] = [];
    for (let remaining = size; remaining > 0;) {
      const chunk = new Uint8Array(Math.min(remaining, chunkSize));
      await this.tokenizer.readBuffer(chunk);
      chunks.push(chunk);
      remaining -= chunk.length;
    } 
    // Rest of chunk collation follows
  }
}

To exploit this vulnerability, an attacker constructs a minimal binary file containing the structurally valid outer headers of a Monkey's Audio (.ape) container. Inside the APEv2 tag section (APETAGEX), the attacker inserts a tag key (such as Cover Art (Front)) followed by a binary header indicating an inflated payload size, such as 0x08000000 (128 MiB).

Because the layout is verified by the outer parser, the application navigates directly to the APEv2 parser block. Upon extracting the tag item, the code executes new Uint8Array(134217728) to prepare the cover-art container. The application attempts to allocate 128 MiB of memory from the V8 heap, which is immediately dedicated to the buffer backing store. This occurs before the library attempts to stream the actual metadata contents.

When the parser subsequently attempts to read the 128 MiB from the 134-byte payload, it throws an EndOfStreamError. However, because memory allocation was successful, the application retains the allocated memory blocks. Sending multiple parallel parse requests of this type easily triggers heap exhaustion, crashing the single-threaded Node.js worker process.

The impact of this vulnerability is a high-availability threat (Denial of Service). In single-threaded JavaScript execution environments such as Node.js, an Out of Memory (OOM) error terminates the current process instantly. This can cause severe operational issues for APIs, queues, and containerized microservices that process user uploads.

To address this vulnerability, security administrators and developers should immediately update the music-metadata dependency to version 11.16.0 or higher. This update changes the parser's allocation model and implements bounds checking to prevent large, unverified memory reservations.

> [!NOTE] > If updating the library is not immediately feasible, teams can mitigate risks by implementing file size limits at the application layer, blocking ingestion of files with the audio/ape MIME type, or running metadata parsing within isolated, sandboxed subprocesses.