Podatności NLTK

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 przed wersją 3.10.3 zawiera podatność ReDoS w module tgrep. Funkcja _tgrep_node_action kompiluje wyrażenia regularne dostarczone przez użytkownika i wykonuje je bez walidacji, co może prowadzić do katastrofalnego cofania się i zablokowania procesu Pythona.

Wersje NLTK przed 3.10.0 zawierają podatność na odmowę usługi przez wyrażenia regularne w metodach Text.findall() i TokenSearcher.findall(), które akceptują wyrażenia regularne dostarczone przez użytkownika bez walidacji lub limitu czasu. Atakujący mogą dostarczyć spreparowane wzorce regex, które powodują katastrofalne cofanie się, prowadząc do nieograniczonego zużycia procesora i odmowy usługi dla wszystkich użytkowników procesu Pythona.

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 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.

NLTK przed wersją 3.10.3 zawiera podatność na przechodzenie poza katalog (path traversal) w czytnikach korpusów, które ponownie otwierają ścieżki pochodzące z katalogu głównego za pomocą wbudowanej funkcji open() zamiast nltk.pathsec.open(), co pozwala dowiązaniom symbolicznym na ucieczkę z zaufanych katalogów głównych. Atakujący, którzy umieszczą dowiązania symboliczne do plików korpusu w zaufanym katalogu danych, mogą ujawnić zawartość poza katalogiem głównym za pomocą normalnych metod czytnika korpusów, takich jak channels(), domains() i synonyms().

NLTK w wersjach przed 3.10.3 zawiera podatność polegającą na ominięciu sandboxa ścieżek w konstruktorach czytników korpusów, która pozwala atakującym na odczyt plików poza zamierzonym katalogiem danych. Atakujący mogą dostarczyć dowolne ścieżki korpusu do konstruktorów LinThesaurusCorpusReader i PanLexLiteCorpusReader, aby uzyskać dostęp do zawartości systemu plików i baz danych SQLite poza granicami sandboxa pathsec.

NLTK przed wersją 3.10.3 zawiera podatność na podrabianie żądań po stronie serwera (SSRF) w funkcji nltk.pathsec.urlopen (oraz w wywołujących nltk.data.load, nltk.downloader.Downloader.index/download) gdy skonfigurowany jest proxy HTTP. Walidacja hosta odbywa się lokalnie, ale proxy wykonuje faktyczne żądanie do wewnętrznego adresu, który nie jest ponownie weryfikowany.

NLTK przed wersją 3.10.3 używa xml.etree.ElementTree do parsowania XML w wielu modułach, co honoruje deklaracje encji w DTD dokumentu. Atakujący mogą stworzyć złośliwe XML z zagnieżdżonymi encjami, które rozszerzają się z setek bajtów do megabajtów w pamięci, powodując odmowę usługi.

NLTK przed wersją 3.10.3 nie używa zwalidowanych ścieżek bezwzględnych podczas wywoływania binarnego pliku Graphviz dot w dependencygraph.dot2img i AlignedSent._repr_svg_, co pozwala atakującym na wykonanie dowolnego kodu przez umieszczenie złośliwego pliku dot w ścieżce wyszukiwania lub bieżącym katalogu roboczym. Atakujący mogą wykorzystać rozwiązywanie nazw bez ścieżki na Windows przez bieżący katalog roboczy lub na systemach uniksowych przez względne wpisy PATH, aby wykonać swój binarny plik zamiast legalnego narzędzia Graphviz.

NLTK w wersjach przed 3.9.4 zawiera podatność polegającą na obejściu zabezpieczeń przez dowiązania symboliczne w funkcji CorpusReader.open(), co pozwala lokalnym atakującym na odczyt dowolnych plików poza katalogiem korpusu. Walidacja ścieżek jest leksykalna i nie uwzględnia rozwiązywania dowiązań symbolicznych.

NLTK w wersjach przed 3.9.4 zawiera nieograniczoną rekurencję w metodzie JSONTaggedDecoder.decode_obj(), która pozwala atakującym na spowodowanie odmowy usługi poprzez dostarczenie głęboko zagnieżdżonych struktur JSON. Atakujący mogą przygotować ładunki JSON przekraczające limit rekurencji, aby wywołać nieobsłużony błąd RecursionError, który powoduje awarię procesu Pythona.

NLTK w wersjach przed 3.10.0 zawiera błąd logiczny w FileSystemPathPointer.open(), gdzie walidacja piaskownicy porównuje znormalizowaną ścieżkę z samą sobą, co czyni zabezpieczenie trwale nieaktywnym. Atakujący mogą przekazać adresy URL file:// do nltk.data.load(), aby odczytać dowolne pliki dostępne dla użytkownika procesu, w tym dane uwierzytelniające i pliki konfiguracyjne.

NLTK przed wersją 3.10.0 zawiera podatność na dowolny odczyt plików lokalnych w StreamBackedCorpusView, która omija zabezpieczenie pathsec.ENFORCE poprzez bezpośrednie wywołanie builtins.open() zamiast pathsec.open(). Atakujący, którzy kontrolują argument fileid, mogą czytać dowolne pliki lokalne niezależnie od ustawienia ENFORCE, w tym wrażliwe pliki systemowe i poświadczenia aplikacji.

NLTK przed wersją 3.10.0 (dotknięte wersje <= 3.9.4) zawiera podatność na podrabianie żądań po stronie serwera (SSRF) w funkcji validate_network_url() w nltk/pathsec.py. Pomocnicza funkcja _resolve_hostname() łapie OSError i ValueError podczas socket.getaddrinfo() i zwraca pustą listę; gdy rozwiązywanie DNS zawiedzie, pętla walidacyjna nie wykonuje żadnych kontroli IP i funkcja zawodzi w trybie otwartym, pozwalając urlopen() na działanie bez walidacji.

NLTK przed wersją 3.9.3 nie weryfikuje integralności plików po pobraniu pakietów i przed ich rozpakowaniem w module downloader. Atakujący mogą przeprowadzić ataki man-in-the-middle lub zatrucie DNS, aby wstrzyknąć złośliwą zawartość pakietów, która jest rozpakowywana bez walidacji.

NLTK w wersjach przed 3.10.0 domyślnie ustawia ENFORCE=False w pathsec.py, co powoduje, że wszystkie funkcje walidacji bezpieczeństwa emitują ostrzeżenia zamiast zgłaszać wyjątki. Atakujący mogą ominąć zabezpieczenia przed path traversal i deserializacją pickle, wykorzystując wyłączone kontrolki bezpieczeństwa, które są aktywne tylko po ręcznym włączeniu.

NLTK w wersjach przed 3.10.0 zawiera podatność na przechodzenie po ścieżkach w FramenetCorpusReader i NKJPCorpusReader, która pozwala atakującym na parsowanie plików XML poza katalogiem korpusu poprzez dostarczenie niebezpiecznych selektorów lub zatrutego stanu indeksu. Atakujący mogą wykorzystać metody frame_by_name, doc, lu i header z spreparowanymi parametrami do odczytu dowolnych plików XML dostępnych dla aplikacji.

NLTK w wersjach przed 3.10.2 zawiera podatność na ominięcie piaskownicy przez dowiązania symboliczne w FramenetCorpusReader, która pozwala atakującym na odczyt dowolnych plików XML poza katalogiem korpusu. Atakujący mogą umieścić dowiązania symboliczne z nazwami nie zawierającymi separatorów ścieżek w podkatalogu korpusu, które przechodzą walidację ścieżki i są rozwiązywane do plików poza zamierzonym katalogiem korpusu podczas dostępu przez metody frame_by_name(), _lu_file() lub doc().

NLTK przed wersją 3.10.2 zawiera podatność na arbitralny odczyt plików przez dowiązania symboliczne w metodach IPIPANCorpusReader, które całkowicie omijają walidację nltk.pathsec. Atakujący może umieścić dowiązanie symboliczne w katalogu głównym korpusu i odczytać dowolne pliki dostępne dla procesu, wywołując metody channels(), domains(), categories() lub fileids() z nazwą dowiązania.

NLTK 3.9.4 do 3.10.2 zawiera podatność na path traversal w CrubadanCorpusReader. _load_lang_ngrams łączy korzeń korpusu z crubadan_code, wartością z kolumny 0 odczytaną z pliku mapowania corpus table.txt, i otwiera wynik za pomocą wbudowanego open() zamiast walidowanego przez pathsec otwieracza, więc os.path.join odrzuca korzeń, gdy ta wartość jest absolutna, a odczyt wychodzi poza katalog korpusu bez sprawdzenia zawartości, które nltk.pathsec stosuje, gdy ENFORCE jest ustawione. Atakujący, który kontroluje pakiet korpusu, może ujawnić zawartość plików poza korzeniem korpusu przez lang_freq, ograniczone do ścieżek kończących się na -3grams.txt, których zawartość parsuje się jako linie z liczbą tokenów.

NLTK przed wersją 3.10.3 zawiera podatność na zdalne wykonanie kodu w AllowlistUnpickler, który waliduje tylko nazwę modułu pickle, a nie nazwę globalną, co pozwala atakującym na rozwiązywanie nazw z kropkami przez atrybuty do wywoływalnych obiektów spoza dozwolonej przestrzeni nazw. Atakujący mogą stworzyć niezaufane modele parsera przejść, które wykonują dowolne polecenia, gdy TransitionParser.parse ładuje model przez allowlisted_pickle_load.

Wyrażenie regularne URLS w nltk/tokenize/casual.py, używane przez TweetTokenizer, zawiera nieograniczoną gałąź domeny, co prowadzi do katastrofalnego cofania się (backtracking) przy przetwarzaniu złośliwych danych wejściowych. Kilka kilobajtów tekstu może spowodować wielominutowe zużycie CPU, co umożliwia atak DoS bez uwierzytelnienia. Wersja 3.10.1 ogranicza powtarzanie etykiet.

Podatność typu Server-Side Request Forgery (SSRF) istnieje w nltk/nltk w wersji 3.9.4 i w bieżącej gałęzi develop. Funkcja nltk.pathsec.validate_network_url(), mająca zapobiegać SSRF poprzez odrzucanie adresów sieci wewnętrznej, nie odrzuca adresów IP z przestrzeni współdzielonej RFC 6598 (100.64.0.0/10). Dzieje się tak, ponieważ moduł ipaddress w Pythonie nie klasyfikuje takich adresów jako is_private ani is_global, a obecna kontrola sprawdza tylko is_private i kilka jawnych kategorii. Atakujący, który może wpływać na URL przekazywany do pomocników ładowania sieciowego NLTK, może wykorzystać tę podatność, aby aplikacja w trybie ścisłym wysyłała żądania do hostów w przestrzeni współdzielonej, potencjalnie ujawniając niepubliczną infrastrukturę dostępną z hosta aplikacji. Wpływ ogranicza się do ujawnienia poufności w stylu SSRF, bez deklaracji wykonania kodu.

Podatność w `nltk.downloader` w nltk/nltk w wersjach do 3.9.4 umożliwia zatruwanie zasobów i modeli między pakietami. Pobieracz rozpakowuje archiwa pakietów do wspólnych przestrzeni nazw, takich jak `corpora/` i `taggers/`, zamiast do izolowanych katalogów pakietów, a integralność pakietu jest weryfikowana dopiero po zapisaniu i rozpakowaniu archiwum. Ta wada projektowa umożliwia jednemu pakietowi nadpisanie zaufanych zasobów innego pakietu w tej samej przestrzeni nazw, co czyni zmiany natychmiast aktywnymi przez zwykłe API NLTK. Problem utrzymuje się po ponownym uruchomieniu interpretera i może wpływać na potoki uczenia maszynowego i środowiska wrażliwe na powtarzalność.

W nltk w wersji 3.9.4 funkcja `nltk.downloader.Downloader._download_package()` zapisuje pobrane bajty pakietu na dysk i może je rozpakować przed wymuszeniem walidacji sum kontrolnych SHA-256 lub MD5. Umożliwia to atakującemu manipulację treścią pakietu poprzez skompromitowane mirror, złośliwy proxy lub inne podmiany źródła, prowadząc do instalacji kontrolowanych przez atakującego pakietów.

NLTK (Natural Language Toolkit) przed wersją 3.9.3 zawiera podatność na wstrzyknięcie eval w module nltk.collocations. Gdy collocations.py jest wywoływany bezpośrednio, argumenty wiersza poleceń są przekazywane do eval() bez walidacji, co umożliwia atakującemu wykonanie dowolnego kodu Python, w tym poleceń systemowych przez moduł os.

W bibliotece nltk w wersjach 3.9.3 i wcześniejszych pięć klas interfejsu Stanforda (StanfordPOSTagger, StanfordNERTagger, StanfordParser, StanfordDependencyParser i StanfordNeuralDependencyParser) jest podatnych na wykonanie niezaufanego kodu JAR. Klasy te akceptują kontrolowane przez użytkownika ścieżki JAR i wykonują je przez funkcję `java()`, która wywołuje `subprocess.Popen()` bez weryfikacji integralności. Podatność jest identyczna z CVE-2026-0848, która została naprawiona dla StanfordSegmenter przez dodanie weryfikacji SHA256, ale poprawka nie została zastosowana do tych dodatkowych klas.

W bibliotece NLTK (Natural Language Toolkit) w wersjach przed 3.10.0-rc1 wykryto podatność na path traversal w funkcji nltk.data.load() przy użyciu schematu URL nltk:. Atakujący może ominąć zabezpieczenia poprzez zakodowane w URL-u separatory ścieżek (np. %2f, %2e%2e), co pozwala na odczyt dowolnych plików z systemu plików.

W bibliotece NLTK (Natural Language Toolkit) w wersjach 3.9.3 i wcześniejszych, mechanizm pobierania nie weryfikuje atrybutów `subdir` i `id` podczas przetwarzania zdalnych plików indeksu XML. Atakujący może kontrolować zdalny serwer XML, aby dostarczyć złośliwe wartości zawierające sekwencje przejścia do katalogu nadrzędnego (np. `../`), co umożliwia tworzenie dowolnych katalogów, plików oraz nadpisywanie istniejących plików.

Podatność w bibliotece NLTK (Natural Language Toolkit) w wersjach 3.9.3 i wcześniejszych umożliwia nieuwierzytelnionemu atakującemu zdalne zatrzymanie lokalnego serwera HTTP WordNet Browser poprzez wysłanie żądania GET /SHUTDOWN%20THE%20SERVER. Powoduje to natychmiastowe zakończenie procesu za pomocą os._exit(0), co prowadzi do odmowy usługi (DoS).

Funkcja `filestring()` w module `nltk.util` biblioteki NLTK w wersji 3.9.2 zawiera podatność na odczyt dowolnych plików z powodu braku walidacji ścieżek wejściowych. Funkcja otwiera pliki wskazane przez użytkownika bez odpowiedniego oczyszczania, co umożliwia atakującym dostęp do wrażliwych plików systemowych poprzez podanie ścieżek absolutnych lub wykorzystanie przejść katalogowych.

Podatność w bibliotece NLTK w wersjach do 3.9.2 umożliwia odczyt dowolnych plików poprzez przejście ścieżki w klasach CorpusReader. Brak walidacji ścieżek plików pozwala atakującym na dostęp do poufnych danych na serwerze.

Krytyczna podatność w komponencie pobierania NLTK (nltk/nltk) we wszystkich wersjach. Funkcja _unzip_iter w nltk/downloader.py używa zipfile.extractall() bez walidacji ścieżek, co pozwala atakującym na wstrzyknięcie złośliwych pakietów ZIP. Po rozpakowaniu i zaimportowaniu plików Python (np. __init__.py) dochodzi do zdalnego wykonania kodu.