Wersje biblioteki NLTK starsze niż 3.10.0-rc1 zawierają krytyczną podatność typu Path Traversal 1. NLTK (Natural Language Toolkit) to popularny zestaw modułów Pythona, używany w badaniach i komercyjnych projektach z zakresu przetwarzania języka naturalnego 2. Luka pozwala atakującemu na odczyt dowolnych plików z systemu, na którym uruchomiona jest aplikacja wykorzystująca podatną wersję biblioteki 3.

Problem dotyczy sposobu, w jaki funkcja nltk.data.load() przetwarza specjalnie spreparowane ścieżki URL 4. Błąd w logice walidacji wejścia umożliwia ominięcie zabezpieczeń i dostęp do zasobów poza wyznaczonym katalogiem. Aktualizacja do najnowszej wersji jest jedynym skutecznym sposobem ograniczenia tego zagrożenia.

TL;DR

  • Produkt: NLTK (Natural Language Toolkit), biblioteka Python.
  • Wektor: Path Traversal w funkcji nltk.data.load() przy użyciu schematu nltk:. 4
  • CVE-ID: CVE-2026-54293.
  • Podsumowanie IoC: Brak typowych wskaźników kompromitacji (IoC). Zagrożenie polega na możliwości wykorzystania luki w kodzie. Operator może odczytać dowolny plik, np. /etc/passwd lub pliki konfiguracyjne aplikacji, poprzez spreparowanie ścieżki z zakodowanymi znakami ../.
  • Kogo dotyczy: Polskie software house’y, zespoły data science, instytucje badawcze i firmy tworzące rozwiązania oparte o AI/ML, które korzystają z biblioteki NLTK w wersjach starszych niż 3.10.0-rc1. 1
  • Pierwszy ruch reagowania: Natychmiastowa aktualizacja biblioteki NLTK do wersji 3.10.0-rc1 lub nowszej we wszystkich środowiskach (deweloperskich, testowych, produkcyjnych).

Wektor ataku

Podatność zidentyfikowana jako CVE-2026-54293 to klasyczny przykład błędu typu „decode-after-check” 5. Oznacza to, że biblioteka najpierw sprawdza dostarczoną przez użytkownika ścieżkę pod kątem niebezpiecznych sekwencji, a dopiero potem ją dekoduje.

Mechanizm ataku jest następujący:

  1. Atakujący przekazuje do funkcji nltk.data.load() ścieżkę zasobu w formacie URL, używając schematu nltk:. 4
  2. Ścieżka zawiera znaki traversalu (../), ale są one zakodowane w formacie URL (np. %2e%2e%2f). 6
  3. Wbudowane w NLTK wyrażenie regularne unsafe-path sprawdza ścieżkę przed zdekodowaniem. 7 Poprawnie blokuje literały takie jak ../../../etc/passwd, ale przepuszcza ich zakodowane odpowiedniki 8, co wynika z tego, że zakodowane warianty, takie jak %2fetc%2fpasswd, %2e%2e%2f... i ..%2f..%2f, omijają wyrażenie regularne i są następnie dekodowane do rzeczywistej ścieżki systemu plików 6.
  4. Po przejściu walidacji, biblioteka używa funkcji url2pathname(), która dekoduje sekwencje %xx do ich właściwych znaków. 7
  5. W rezultacie zakodowana ścieżka %2e%2e%2f%2e%2e%2fetc%2fpasswd zostaje zamieniona na ../../etc/passwd, co pozwala na wyjście z dozwolonego katalogu i odczyt dowolnego pliku na serwerze, do którego proces ma uprawnienia. 3

Ta technika pozwala ominąć zabezpieczenia opisane w dokumentacji SECURITY.md projektu NLTK. 3 Dla polskich firm, które przetwarzają dane wrażliwe lub dane osobowe podlegające pod RODO (Rozporządzenie o Ochronie Danych Osobowych), ryzyko jest znaczne. Wyciek plików konfiguracyjnych, kluczy API czy baz danych może prowadzić do poważnych incydentów bezpieczeństwa i kar finansowych.

Wskaźniki kompromitacji

Ponieważ jest to luka w oprogramowaniu, a nie aktywna kampania złośliwego oprogramowania, nie ma stałych wskaźników kompromitacji (IoC), takich jak hashe plików czy adresy IP serwerów C2 (Command and Control — serwer kontrolujący zainfekowane maszyny).

Zamiast tego należy skupić się na audycie kodu i logów serwerów aplikacyjnych. Warto szukać prób wywołania funkcji nltk.data.load() z nietypowymi, zakodowanymi ścieżkami, zwłaszcza zawierającymi wielokrotne segmenty przejścia do katalogu nadrzędnego. Nie publikujemy gotowego kodu wykorzystującego lukę. Analiza takich sekwencji w kontekście wywołań API opartych o NLTK może pomóc w wykryciu prób ataku.

Co zrobić w 24-48h

Kroki naprawcze należy podjąć natychmiast, zwłaszcza w środowiskach produkcyjnych.

  1. Identyfikacja i aktualizacja: Priorytetem jest zidentyfikowanie wszystkich projektów i systemów używających biblioteki NLTK. Należy sprawdzić pliki requirements.txt, Pipfile, poetry.lock lub inne mechanizmy zarządzania zależnościami. Wszystkie instancje NLTK w wersji starszej niż 3.10.0-rc1 muszą zostać zaktualizowane. 9

    pip install --upgrade nltk

  2. Audyt kodu: Należy przeprowadzić przegląd kodu w poszukiwaniu miejsc, gdzie funkcja nltk.data.load() jest wywoływana z danymi pochodzącymi z zewnętrznego, niezaufanego źródła (np. parametrów żądania HTTP). Nawet po aktualizacji, jest to dobra praktyka w ramach utwardzania bezpieczeństwa aplikacji.

  3. Kontekst polski: Polskie firmy z sektora FinTech, MedTech oraz software house’y budujące produkty dla klientów zagranicznych powinny potraktować ten alert priorytetowo. Wyciek danych może naruszyć nie tylko RODO, ale także inne regulacje sektorowe.

  4. Analiza logów: Zespoły SOC (Security Operations Center — zespół monitoringu bezpieczeństwa) lub administratorzy powinni przeanalizować historyczne logi aplikacyjne i logi serwerów webowych pod kątem podejrzanych wzorców opisanych w sekcji powyżej. Może to wskazać, czy luka była już wykorzystywana w przeszłości.

  5. Weryfikacja środowisk: Nie należy zapominać o środowiskach deweloperskich, testowych i CI/CD. Często są one gorzej chronione, a mogą zawierać klucze dostępowe lub inne wrażliwe dane, które mogą zostać wykradzione przy użyciu tej luki. Rekomendowane podejście nie zastępuje pełnego audytu bezpieczeństwa ani konsultacji ze specjalistami. Jest to pierwszy, niezbędny krok w celu zabezpieczenia systemów.

Źródła

Zobacz też

Przypisy

  1. Przed wersją 3.10.0-rc1, funkcja nltk.data.load() w NLTK jest podatna na atak path traversal. — nvd.nist.gov › CVE 2026 54293 ↩ ↩2

  2. NLTK (Natural Language Toolkit) to zestaw modułów open source Pythona, zbiorów danych i samouczków wspierających badania i rozwój w przetwarzaniu języka naturalnego. — nvd.nist.gov › CVE 2026 54293 ↩

  3. Luka pozwala atakującemu ominąć ochronę udokumentowaną w pliku SECURITY.md NLTK i odczytać dowolne pliki z systemu plików. — nvd.nist.gov › CVE 2026 54293 ↩ ↩2 ↩3

  4. Luka path traversal występuje poprzez separatory ścieżek zakodowane w URL i segmenty traversalu, gdy używany jest schemat URL ‘nltk:’. — nvd.nist.gov › CVE 2026 54293 ↩ ↩2 ↩3

  5. Jest to klasyczna wada typu ‘decode-after-check’ / ‘TOCTOU-style flaw’. — nvd.nist.gov › CVE 2026 54293 ↩

  6. Zakodowane warianty, takie jak %2fetc%2fpasswd, %2e%2e%2f… i ..%2f..%2f, omijają wyrażenie regularne i są następnie dekodowane do rzeczywistej ścieżki systemu plików. — nvd.nist.gov › CVE 2026 54293 ↩ ↩2

  7. Sprawdzenie wyrażenia regularnego ‘unsafe-path’ jest wykonywane przed tym, jak url2pathname() dekoduje sekwencje %xx. — nvd.nist.gov › CVE 2026 54293 ↩ ↩2

  8. Literalne ciągi traversalu, takie jak ../../../etc/passwd, są poprawnie blokowane. — nvd.nist.gov › CVE 2026 54293 ↩

  9. Ta luka została naprawiona w wersji 3.10.0-rc1. — nvd.nist.gov › CVE 2026 54293 ↩