CVE-2026-107389: 
JavaScript vulnerability analysis and mitigation

CVE-2026-107389 is a memory allocation vulnerability ("EBML parser trusts element lengths, allowing memory exhaustion or process abort") in the music-metadata npm package by Borewit. The Matroska/WebM EBML parser decodes attacker-controlled variable-length integer (VINT) element lengths without validating that the declared element fits within its enclosing container or available input, enabling denial-of-service attacks via crafted media files. All versions prior to 11.16.0 are affected. The vulnerability was published on October 8, 2026, and carries a CVSS v3.1 base score of 6.2 (Medium) (GitHub Advisory).

The root cause is classified as CWE-789 (Memory Allocation with Excessive Size Value). In EbmlIterator.readElement(), the EBML VINT-encoded element length is decoded and converted to a JavaScript Number without being checked against the parent container boundary or known file size before being passed to leaf readers (readString() and readBuffer()). Since EBML size VINTs can encode values approaching 2^56, a crafted file can route an arbitrarily large declared size into a StringType token or Uint8Array allocation before the tokenizer discovers the input is truncated. Demonstrated outcomes include a 34-byte input causing ~128 MiB allocation, a 70-byte input causing ~500 MiB allocation, and a 48-byte file triggering an uncatchable V8 fatal abort (Fatal error: Check failed: change_in_bytes < kMaxReasonableBytes, exit code 133) via parseFile on Node.js 26.7.0 — which bypasses application-level try/catch. The flaw affects all entry points: parseBuffer, parseFile, parseStream, parseBlob, and parseWebStream (GitHub Advisory, Fix PR #2735).

The impact is limited exclusively to availability — no confidentiality or integrity impact has been demonstrated. Applications that parse untrusted Matroska, WebM, or MKA media files using a vulnerable version of music-metadata can be crashed or rendered unresponsive through disproportionate memory allocations or uncatchable V8 process aborts. Concurrent parses multiply memory consumption, amplifying the denial-of-service effect, and the fatal-abort path on Node.js 26.x cannot be caught by application error handlers, making recovery impossible without a process restart (GitHub Advisory).

A public proof-of-concept exploit is available in the GitHub Security Advisory, consisting of a minimal 15-byte JavaScript payload that triggers the vulnerability via parseBuffer. The PoC was independently reported by four researchers (@bg0d-glitch, @Zwique, @offset, @arpitjain099) and confirmed with high confidence by Feedly's exploit analysis. No in-the-wild exploitation has been observed. The EPSS score is 0.00117 (low probability of exploitation in the near term), and the vulnerability is not listed in the CISA KEV catalog. NVD SSVC classifies exploitation status as "poc" and the attack as non-automatable (GitHub Advisory).

1. Identify target: Locate an application that accepts user-supplied media files (WebM, MKV, or MKA) and processes them with music-metadata versions prior to 11.16.0 (e.g., a media upload endpoint, a streaming service, or a metadata extraction API).
2. Craft malicious payload: Construct a minimal EBML/WebM buffer with an oversized VINT-encoded element length. A minimal buffer-based PoC uses a docType string element with an eight-byte VINT declaring a near-maximal length:

const payload = Uint8Array.from([
  0x1a, 0x45, 0xdf, 0xa3, 0x8a,  // EBML header ID + size
  0x42, 0x82,                      // docType element ID
  0x01, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff  // oversized 8-byte VINT length
]);

3. Submit to parser: Deliver the crafted file or buffer to the target application's media parsing endpoint (e.g., upload as a .webm file or pass directly to parseBuffer/parseFile).
4. Trigger allocation: The EBML iterator decodes the attacker-controlled length and passes it to readString() or readBuffer(), which attempts to allocate a StringType token or Uint8Array of the declared size before discovering the input is truncated.
5. Achieve DoS: Depending on the runtime and API path, the result is either an out-of-memory crash, a catchable error after excessive allocation, or (on Node.js 26.x via parseFile) an uncatchable V8 fatal abort that terminates the process with exit code 133, bypassing all application-level error handling (GitHub Advisory).

• Network: Repeated uploads or submissions of very small WebM/MKV/MKA files (under 100 bytes) to media parsing endpoints; unusual patterns of tiny media file submissions from a single source IP.
• Process: Node.js process terminating unexpectedly with exit code 133 accompanied by a V8 fatal error message (Fatal error: Check failed: change_in_bytes < kMaxReasonableBytes); sudden spikes in memory consumption by the Node.js process handling media parsing.
• Logs: Application logs showing uncaught fatal errors or process restarts correlated with media file processing; error messages referencing EbmlContentError or EBML parsing failures (post-patch) that indicate attempted exploitation against a patched system.
• File System: Presence of anomalously small .webm, .mkv, or .mka files (under 100 bytes) in upload directories or temporary storage that do not correspond to valid media content (GitHub Advisory).

Upgrade music-metadata to version 11.16.0 or later, which validates EBML leaf lengths against parent container and file boundaries before any allocation, and reads large leaves from streams incrementally to prevent single large allocations (v11.16.0 Release, Fix PR #2735). As interim mitigations where upgrading is not immediately possible: restrict the size of accepted media files to a reasonable maximum before passing them to the parser; sandbox the media parsing process (e.g., in a worker thread or child process) to contain the blast radius of memory exhaustion or fatal aborts; and avoid parsing untrusted Matroska/WebM media in environments running Node.js 26.x where the fatal-abort path is reachable (GitHub Advisory).