CVE-2026-107387

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 publicznej wersji rozwojowej music-metadata wprowadzonej po 11.14.0 regresja w gałęzi rozwojowej parsera opisu próbki MP4 stsd pozwala na kontrolowany przez atakującego rozmiar wpisu próbki równy zero, co uniemożliwia przesunięcie kursora StsdAtom.get, podczas gdy kontrolowany przez atakującego entry_count utrzymuje działanie pętli synchronicznej. Spreparowane dane wejściowe z rodziny MP4 mogą zablokować pętlę zdarzeń Node.js i zwiększać tabelę opisu próbek, aż proces zostanie zakończony lub wyczerpie pamięć. Podatna zmiana była obecna w publicznej gałęzi master, ale nie została uwzględniona w music-metadata 11.14.0 ani żadnym wcześniejszym wydaniu npm, a wersja 11.16.0 zawiera poprawkę.

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.