CVE-2026-0847

NLTK w wersjach do 3.10.3 zawiera podatność przechodzenia ścieżki w WekaClassifier, która pozwala atakującym na obejście zabezpieczenia nltk.pathsec poprzez dostarczenie niezwalidowanych ścieżek modeli. Atakujący kontrolujący argument model_filename lub model mogą zmusić JVM weka do zapisu plików poprzez -d lub sondowania plików poprzez -l poza dozwolonymi katalogami danych.

NLTK przed wersją 3.10.3 nie waliduje opcji JVM przekazywanych przez parametr options w funkcji java(), co pozwala atakującym na wstrzykiwanie niebezpiecznych flag JVM. Atakujący mogą dostarczyć złośliwe opcje, takie jak -agentpath, -javaagent lub @argfile, do klas opakowujących Stanford, aby osiągnąć wykonanie dowolnego kodu.

NLTK przed wersją 3.10.3 zawiera podatność na zdalne wykonanie kodu w loaderach pickle, które ufają całym przestrzeniom nazw modułów zamiast konkretnym bezpiecznym funkcjom. Atakujący mogą stworzyć złośliwe ładunki pickle, które wywołują niebezpieczne funkcje, takie jak ReppTokenizer._execute czy numpy.f2py.crackfortran.myeval, podczas ładowania modeli lub artefaktów tokenizera.

NLTK przed wersją 3.10.0 zawiera podatność na niebezpieczną deserializację pickle w metodzie TransitionParser.parse(). Deserializacja odbywa się z domyślnym ustawieniem restricted=False, co pozwala na wykonanie dowolnego kodu Pythona podczas ładowania spreparowanego pliku modelu.

NLTK przed wersją 3.10.3 zawiera podatność na obejście ograniczeń systemu plików w metodach Downloader.download i Downloader.incr_download, umożliwiającą atakującym nadpisywanie plików poza katalogiem instalacyjnym przez istniejące twarde dowiązania. Atakujący z dostępem do zapisu w współdzielonym katalogu downloadera może tworzyć twarde dowiązania do plików poza katalogiem, które są nadpisywane podczas normalnej ekstrakcji pakietów.

NLTK do wersji 3.10.3 zawiera podatność na przechodzenie po ścieżkach (path traversal) w API artefaktów modeli, która omija egzekwowanie pathsec poprzez użycie surowych operacji na plikach na ścieżkach kontrolowanych przez wywołującego. Atakujący mogą czytać lub zapisywać pliki poza dozwolonymi katalogami sandboxa przez API TransitionParser, AveragedPerceptron, PerceptronTagger i maxent, gdy pathsec jest włączone.

NLTK przed wersją 3.10.3 zawiera podatność na regular expression denial of service w Pl196xCorpusReader. Atakujący może dostarczyć złośliwe bloki TEI z wieloma niepasującymi tagami otwierającymi, powodując nadmierne zużycie CPU.

NLTK przed wersją 3.10.3 zawiera podatność na niekontrolowaną rekurencję w nltk.featstruct.FeatStructReader, która pozwala nieuwierzytelnionym atakującym na spowodowanie odmowy usługi poprzez dostarczenie głęboko zagnieżdżonych danych wejściowych struktury cech. Atakujący mogą tworzyć trywialne ładunki z zagnieżdżonymi nawiasami, które przekraczają limit rekurencji Pythona i wywołują nieobsłużony błąd RecursionError, powodując awarię aplikacji przetwarzających struktury cech lub gramatyki cech dostarczane przez użytkownika.

NLTK przed wersją 3.10.3 zawiera podatność na wyczerpanie CPU w XMLCorpusView._read_xml_fragment(). Atakujący może dostarczyć złośliwe pliki XML, powodując poważne zużycie procesora i DoS.

NLTK PorterStemmer w wersjach do 3.10.2 (poprawione w 3.10.3) zawiera podatność na odmowę usługi przez nieefektywną złożoność algorytmiczną w metodzie stem(). Funkcja _is_consonant() przegląda wstecz cały ciąg końcowych znaków 'y' przy każdym wywołaniu, a _measure() wywołuje ją dla każdej pozycji rdzenia, co powoduje złożoność O(n^2). Pojedynczy token o długości 20-50 KB składający się z długiego ciągu litery 'y' i pasującego przyrostka (np. 'ness') może zająć CPU na sekundy lub minuty.