CVE-2026-107389

music-metadata is a metadata parser for audio and video media files. Prior to 11.16.0, the Matroska and WebM EBML parser decodes an attacker-controlled VINT element length and uses it for string-token or Uint8Array allocation before confirming that the leaf fits within its parent or available input. Crafted WebM, MKV, or MKA inputs can cause disproportionate allocations, out-of-memory denial of service, or, for a demonstrated parseFile path on Node.js 26.7.0, an uncatchable V8 fatal abort. The exact failure mode depends on the tokenizer, parser API, and runtime, but the affected leaf-length validation flaw is shared and has availability impact only. This issue is fixed in version 11.16.0.

music-metadata is a metadata parser for audio and video media files. Prior to 11.16.0, the Matroska and WebM EBML parser decodes an attacker-controlled VINT element length and uses it for string-token or Uint8Array allocation before confirming that the leaf fits within its parent or available input. Crafted WebM, MKV, or MKA inputs can cause disproportionate allocations, out-of-memory denial of service, or, for a demonstrated parseFile path on Node.js 26.7.0, an uncatchable V8 fatal abort. The exact failure mode depends on the tokenizer, parser API, and runtime, but the affected leaf-length validation flaw is shared and has availability impact only. This issue is fixed in version 11.16.0.

Summary

The Matroska/WebM EBML parser decodes attacker-controlled variable-length integer (VINT) element lengths without first validating that the declared element fits within its enclosing container or the available input. Leaf lengths are then used directly for string-token and Uint8Array allocations.

A very small crafted .webm, .mkv, or .mka file can therefore cause a disproportionately large allocation, an out-of-memory denial of service, or—in one demonstrated parseFile case—an uncatchable V8 fatal abort.

Impact

Applications that parse untrusted Matroska/WebM media can be denied service. Depending on the input, parser API, and Node.js/V8 version, the demonstrated outcomes include:

• a 34-byte input causing an approximately 128 MiB allocation before end-of-input;
• a 70-byte input causing a 500 MiB allocation through a binary EBML leaf, with concurrent parses multiplying memory consumption;
• a 48-byte file causing an uncatchable V8 fatal abort through parseFile when a leaf declares a length of 32 GiB.

The fatal-abort case was reproduced on music-metadata 11.15.0 with Node.js 26.7.0. It was deterministic across three runs and exited with code 133 despite a surrounding try/catch. The same reporter did not reproduce that fatal abort through parseBuffer on Node.js 20 through 25; those configurations can still encounter allocation attempts or catchable errors. The exact failure mode is therefore runtime- and tokenizer-dependent, but the underlying validation flaw is shared.

The impact is limited to availability; no confidentiality or integrity impact has been demonstrated.

Root cause

EbmlIterator.readElement() decodes an element length from an EBML VINT and converts it to a JavaScript Number:

private async readElement(): Promise<IHeader> {
  const id = await this.readVintData(this.ebmlMaxIDLength);
  const lenField = await this.readVintData(this.ebmlMaxSizeLength);
  lenField[0] ^= 0x80 >> (lenField.length - 1);
  return {
    id: readUIntBE(id, id.length),
    len: readUIntBE(lenField, lenField.length)
  };
}

Before the fix, that value was not checked against the parent boundary or known file size before reaching the leaf readers:

private async readString(e: IHeader): Promise<string> {
  const rawString = await this.tokenizer.readToken(new StringType(e.len, 'utf-8'));
  return rawString.replace(/\x00.*$/g, '');
}

private async readBuffer(e: IHeader): Promise<Uint8Array> {
  const buf = new Uint8Array(e.len);
  await this.tokenizer.readBuffer(buf);
  return buf;
}

An EBML size VINT can encode values approaching 2^56. A crafted file can select a known string, unsigned-integer, binary, or UID element and route its declared size into an allocation before the tokenizer discovers that the input is truncated. The declared length also participates in container-boundary arithmetic.

For lengths around 32 GiB, one reporter observed V8 aborting on its external-memory accounting check:

Fatal error: Check failed: change_in_bytes < kMaxReasonableBytes
process exit code 133

This is a V8 process abort rather than a JavaScript exception, so application-level error handling cannot catch it.

Attack scenarios

The issue is reachable through ordinary metadata parsing of attacker-controlled Matroska/WebM files. Reported proofs of concept exercised string, unsigned-integer, binary, and UID leaves. Depending on the tokenizer and runtime, affected entry points include parseBuffer, parseFile, parseStream, parseBlob, and parseWebStream.

One minimal buffer-based proof of concept uses a docType string with an oversized eight-byte VINT:

import { parseBuffer } from 'music-metadata';

const payload = Uint8Array.from([
  0x1a, 0x45, 0xdf, 0xa3, 0x8a,
  0x42, 0x82,
  0x01, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff
]);

await parseBuffer(payload, { mimeType: 'video/webm' });

Another proof of concept used a valid WebM EBML header followed by an…

music-metadata is a metadata parser for audio and video media files. Prior to 11.16.0, the Matroska and WebM EBML parser decodes an attacker-controlled VINT element length and uses it for string-token or Uint8Array allocation before confirming that the leaf fits within its parent or available input. Crafted WebM, MKV, or MKA inputs can cause disproportionate allocations, out-of-memory denial of service, or, for a demonstrated parseFile path on Node.js 26.7.0, an uncatchable V8 fatal abort. The exact failure mode depends on the tokenizer, parser API, and runtime, but the affected leaf-length validation flaw is shared and has availability impact only. This issue is fixed in version 11.16.0.

music-metadata is a metadata parser for audio and video media files. Prior to 11.16.0, the Matroska and WebM EBML parser decodes an attacker-controlled VINT element length and uses it for string-token or Uint8Array allocation before confirming that the leaf fits within its parent or available input. Crafted WebM, MKV, or MKA inputs can cause disproportionate allocations, out-of-memory denial of service, or, for a demonstrated parseFile path on Node.js 26.7.0, an uncatchable V8 fatal abort. The exact failure mode depends on the tokenizer, parser API, and runtime, but the affected leaf-length validation flaw is shared and has availability impact only. This issue is fixed in version 11.16.0.

Summary

The Matroska/WebM EBML parser decodes attacker-controlled variable-length integer (VINT) element lengths without first validating that the declared element fits within its enclosing container or the available input. Leaf lengths are then used directly for string-token and Uint8Array allocations.

A very small crafted .webm, .mkv, or .mka file can therefore cause a disproportionately large allocation, an out-of-memory denial of service, or—in one demonstrated parseFile case—an uncatchable V8 fatal abort.

Impact

Applications that parse untrusted Matroska/WebM media can be denied service. Depending on the input, parser API, and Node.js/V8 version, the demonstrated outcomes include:

• a 34-byte input causing an approximately 128 MiB allocation before end-of-input;
• a 70-byte input causing a 500 MiB allocation through a binary EBML leaf, with concurrent parses multiplying memory consumption;
• a 48-byte file causing an uncatchable V8 fatal abort through parseFile when a leaf declares a length of 32 GiB.

The fatal-abort case was reproduced on music-metadata 11.15.0 with Node.js 26.7.0. It was deterministic across three runs and exited with code 133 despite a surrounding try/catch. The same reporter did not reproduce that fatal abort through parseBuffer on Node.js 20 through 25; those configurations can still encounter allocation attempts or catchable errors. The exact failure mode is therefore runtime- and tokenizer-dependent, but the underlying validation flaw is shared.

The impact is limited to availability; no confidentiality or integrity impact has been demonstrated.

Root cause

EbmlIterator.readElement() decodes an element length from an EBML VINT and converts it to a JavaScript Number:

private async readElement(): Promise<IHeader> {
  const id = await this.readVintData(this.ebmlMaxIDLength);
  const lenField = await this.readVintData(this.ebmlMaxSizeLength);
  lenField[0] ^= 0x80 >> (lenField.length - 1);
  return {
    id: readUIntBE(id, id.length),
    len: readUIntBE(lenField, lenField.length)
  };
}

Before the fix, that value was not checked against the parent boundary or known file size before reaching the leaf readers:

private async readString(e: IHeader): Promise<string> {
  const rawString = await this.tokenizer.readToken(new StringType(e.len, 'utf-8'));
  return rawString.replace(/\x00.*$/g, '');
}

private async readBuffer(e: IHeader): Promise<Uint8Array> {
  const buf = new Uint8Array(e.len);
  await this.tokenizer.readBuffer(buf);
  return buf;
}

An EBML size VINT can encode values approaching 2^56. A crafted file can select a known string, unsigned-integer, binary, or UID element and route its declared size into an allocation before the tokenizer discovers that the input is truncated. The declared length also participates in container-boundary arithmetic.

For lengths around 32 GiB, one reporter observed V8 aborting on its external-memory accounting check:

Fatal error: Check failed: change_in_bytes < kMaxReasonableBytes
process exit code 133

This is a V8 process abort rather than a JavaScript exception, so application-level error handling cannot catch it.

Attack scenarios

The issue is reachable through ordinary metadata parsing of attacker-controlled Matroska/WebM files. Reported proofs of concept exercised string, unsigned-integer, binary, and UID leaves. Depending on the tokenizer and runtime, affected entry points include parseBuffer, parseFile, parseStream, parseBlob, and parseWebStream.

One minimal buffer-based proof of concept uses a docType string with an oversized eight-byte VINT:

import { parseBuffer } from 'music-metadata';

const payload = Uint8Array.from([
  0x1a, 0x45, 0xdf, 0xa3, 0x8a,
  0x42, 0x82,
  0x01, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff
]);

await parseBuffer(payload, { mimeType: 'video/webm' });

Another proof of concept used a valid WebM EBML header followed by an…