CVE-2026-107391

W bibliotece music-metadata przed wersją 11.15.0 parser DSF obsługuje nierozpoznany fragment, wywołując tokenizer.ignore bez oczekiwania na zwróconą obietnicę i bez wcześniejszego odrzucenia rozmiaru fragmentu mniejszego niż 12-bajtowy nagłówek. Spreparowane dane wejściowe DSF mogą spowodować ujemną długość ignorowania; w strtok3 10.3.5 lub nowszym wynikowy RangeError jest odłączony od obietnicy parseBuffer i staje się nieobsłużonym odrzuceniem w domyślnym zachowaniu Node.js. Wywołanie parse może wydawać się zakończone sukcesem przed awarią procesu, omijając obsługę try/catch. Wykazany wpływ to jedynie utrata dostępności i wymaga ścieżki parsowania DSF.

W bibliotece music-metadata przed wersją 11.16.0 parser MP4 akceptuje kontrolowany przez atakującego 64-bitowy rozszerzony rozmiar atomu, konwertuje go na liczbę JavaScript i używa wynikowej długości ładunku do wywołań readToken specyficznych dla atomu, zanim udowodni, że atom mieści się w swoim rodzicu lub dostępnych danych wejściowych. Mały plik z rodziny MP4 może skierować zbyt dużą długość do parsowania ładunku dla atomów takich jak mvhd, stsd, stsz i date, powodując próbę dużej alokacji lub awarię procesu przed walidacją końca danych wejściowych. Aplikacje parsujące niezaufane media z rodziny MP4 mogą w związku z tym doświadczyć odmowy usługi.

W bibliotece music-metadata przed wersją 11.16.0 parser EBML dla Matroska i WebM dekoduje kontrolowaną przez atakującego długość elementu VINT i używa jej do alokacji tokenu ciągu lub Uint8Array, zanim potwierdzi, że liść mieści się w swoim rodzicu lub dostępnych danych wejściowych. Spreparowane dane wejściowe WebM, MKV lub MKA mogą powodować nieproporcjonalne alokacje, odmowę usługi z powodu wyczerpania pamięci lub, w wykazanym przypadku ścieżki parseFile w Node.js 26.7.0, nieprzechwytywalne fatalne przerwanie V8. Dokładny tryb awarii zależy od tokenizera, API parsera i środowiska uruchomieniowego, ale wspólna wada walidacji długości liścia ma wpływ tylko na dostępność.

W bibliotece music-metadata przed wersją 11.16.0 parser ID3v2 ufa polu rozmiaru znacznika syncsafe i alokuje całe ciało znacznika, zanim sprawdzi, czy dane wejściowe zawierają zadeklarowane bajty. Obcięty plik zawierający tylko nagłówek ID3v2 może zażądać alokacji zbliżonej do 268 MiB; alokacja się udaje, kolejny odczyt osiąga koniec strumienia, EndOfStreamError jest przechwytywany wewnętrznie, a wywołujący otrzymuje normalny obiekt metadanych.

Przed wersją 11.16.0 parser APEv2 w bibliotece music-metadata odczytuje rozmiar elementu sterowany przez atakującego i przydziela Uint8Array dla elementu binarnego przed sprawdzeniem, czy zadeklarowany rozmiar mieści się w pozostałych danych. Mały spreparowany plik APE może wywołać nieproporcjonalną alokację pamięci, a wielokrotne lub równoległe parsowanie może wyczerpać pamięć procesu. Problem został naprawiony w wersji 11.16.0.