music-metadata: EBML parser trusts element lengths, allowing memory exhaustion or process abort

Why it is Yellow

• CVSS 5.5 medium
• Public exploit or proof of concept referenced
• On your watchlist: npm

Affected packages

References

• https://github.com/advisories/GHSA-5gfj-9q3v-qfp3
• https://github.com/Borewit/music-metadata/security/advisories/GHSA-5gfj-9q3v-qfp3
• https://github.com/Borewit/music-metadata/pull/2735
• https://github.com/Borewit/music-metadata/commit/163f013364ac9fc8dd0c3987433cd065a615af58
• https://github.com/Borewit/music-metadata/commit/2d14dc1f7391a94235948a0b823155538f69b3df
• https://github.com/Borewit/music-metadata/releases/tag/v11.16.0
• https://github.com/advisories/GHSA-5gfj-9q3v-qfp3

Original description

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.