Krytyczna podatność XXE w Apache Tika (CVE-2025-66516, CVSS 10.0) – co musisz załatać już teraz

Wprowadzenie do problemu / definicja luki

W Apache Tika ujawniono krytyczną lukę typu XML External Entity (XXE) oznaczoną jako CVE-2025-66516 z oceną CVSS 10.0. Błąd pozwala na XXE poprzez spreparowany plik XFA osadzony w PDF, co dotyka kluczowych modułów Tiki: tika-core, tika-pdf-module oraz tika-parsers. Projekt wskazuje, że usterka jest ściśle powiązana z wcześniejszym problemem (CVE-2025-54988), ale rozszerza zakres dotkniętych pakietów – dlatego wymaga pilnej aktualizacji nie tylko modułu PDF, lecz także rdzenia (tika-core).

W skrócie

• Zakres podatnych pakietów:
  • org.apache.tika:tika-core 1.13 – 3.2.1 (naprawione w 3.2.2)
  • org.apache.tika:tika-parser-pdf-module 2.0.0 – 3.2.1 (naprawione w 3.2.2)
  • org.apache.tika:tika-parsers 1.13 – 1.28.5 (naprawione od 2.0.0 w górę)
• Wektor ataku: XXE przez XFA w PDF, możliwy odczyt plików, SSRF, a w niektórych scenariuszach DoS.
• Dlaczego nowe CVE? Poprzednie (CVE-2025-54988) skupiało się na module PDF; teraz potwierdzono, że problem i fix są w tika-core, a w gałęzi 1.x parser PDF znajdował się w tika-parsers. Użytkownicy, którzy zaktualizowali wyłącznie moduł PDF, wciąż mogli być podatni.
• Pilne działanie: aktualizacja do Tika 3.2.2 (i odpowiednio do bezpiecznych wersji w gałęzi 2.x) oraz weryfikacja łańcuchów zależności.

Kontekst / historia / powiązania

W sierpniu 2025 ujawniono CVE-2025-54988 – XXE w parserze PDF Tiki. Część organizacji zaktualizowała jedynie moduł PDF, pozostawiając niezałatany tika-core, co utrzymywało okno podatności. Nowe CVE-2025-66516 formalizuje rozszerzony zakres i „zamyka” lukę poprzez wymaganie wersji tika-core ≥ 3.2.2. Dodatkowo w linii 1.x PDFParser był w pakiecie tika-parsers, więc także ten artefakt należy sprawdzić i zaktualizować.

Analiza techniczna / szczegóły luki

Atakujący osadza formularz XFA w dokumencie PDF. Podczas parsowania Tika – zależnie od ścieżki kodu i konfiguracji – może przetworzyć zewnętrzne encje XML (XXE), co umożliwia:

• odczyt lokalnych plików (np. /etc/passwd, klucze, tokeny),
• SSRF – wykonywanie żądań HTTP z serwera aplikacji do zasobów wewnętrznych (np. http://169.254.169.254/ w chmurze),
• w niektórych przypadkach wyciek metadanych i zasobów lub wyczerpywanie zasobów (DoS).
  Problem jest w tika-core, a wejściem bywa moduł PDF; w gałęzi 1.x wejściem mógł być tika-parsers. To tłumaczy, czemu sama aktualizacja modułu PDF nie wystarcza.

Praktyczne konsekwencje / ryzyko

Tika jest powszechnie osadzana w wyszukiwarkach treści, e-discovery, DLP, systemach ETL, serwerach indeksujących, portalach do uploadu plików czy narzędziach bezpieczeństwa. Każda usługa, która przyjmuje PDF od użytkownika i przekazuje do Tiki, może stać się wektorem wycieku danych lub ruchu SSRF do sieci wewnętrznej i usług chmurowych. Instytucje rządowe ostrzegają przed eksfiltracją danych i rekonesansem wewnętrznej sieci przez tę lukę.

Rekomendacje operacyjne / co zrobić teraz

1. Patch teraz
   • Upewnij się, że tika-core = 3.2.2 (lub nowszy), tika-parser-pdf-module = 3.2.2 (lub nowszy) oraz brak artefaktów 1.x (tika-parsers ≤ 1.28.5) w drzewie zależności. W ekosystemach Maven/Gradle wymuś wersje przez dependencyManagement/constraints.
2. Przegląd transytywności
   • Audytuj aplikacje, które pośrednio wciągają Tikę (np. przez narzędzia wyszukiwania, DLP, CMS-y, biblioteki importu). Zadbaj o lockfile i raporty mvn dependency:tree/gradle dependencies. (Wnioski z doradców i ekosystemu GitHub Advisory.)
3. Tymczasowe twardnienie (gdy aktualizacja wymaga okna serwisowego):
   • Odrzuć/izoluj PDF z XFA (np. wstępny „content sniffer” przed Tiką).
   • Sandbox dla procesu parsowania: AppArmor/SELinux, kontenery z restrykcyjnymi profilami, brak dostępu do metadanych chmury, brak sieci lub wyłącznie wyjście przez proxy/egress filter.
   • Limit zasobów (timeouty, limity pamięci/CPU) na pipeline’ach parsowania.
4. Detekcja i reagowanie
   • Szukaj anomalii: żądania do IMDS (169.254.169.254), nietypowe odczyty plików przez usługę parsującą, nadmiarowe błędy parsera PDF.
   • Dodaj reguły w WAF/IDS (sygnatury PDF z XFA, nietypowe nagłówki/URI).
5. Testy bezpieczeństwa
   • Przeprowadź testy jednostkowe/integracyjne z próbkami PDF zawierającymi XFA, aby potwierdzić, że aplikacja nie przetwarza zewnętrznych encji po aktualizacji.

Różnice / porównania z innymi przypadkami

• CVE-2025-54988 vs. CVE-2025-66516: w obu przypadkach wektorem jest XFA w PDF, ale 66516 formalnie poszerza listę podatnych pakietów i wskazuje, że rdzeń (tika-core) zawierał przyczynę – stąd wymóg jego aktualizacji do ≥ 3.2.2. Jeśli załatano tylko moduł PDF, system nadal mógł być podatny.

Podsumowanie / kluczowe wnioski

• To krytyczna luka (CVSS 10.0) w popularnym komponencie przetwarzania dokumentów.
• Aktualizacja tika-core do 3.2.2 (oraz modułów PDF) jest warunkiem koniecznym.
• Przejrzyj wszystkie aplikacje z PDF upload/parsing oraz zależności transytywne – Tika bywa ukryta w wielu platformach.
• Dodaj kontrole prewencyjne (filtrowanie XFA, sandbox, egress filtering) i monitoring pod kątem SSRF/wycieków.

Źródła / bibliografia

• The Hacker News – pierwsza publikacja prasowa i zestawienie wersji dotkniętych/naprawionych. (The Hacker News)
• NVD (NIST) – karta CVE-2025-66516 z oceną CVSS i opisem rozszerzenia zakresu względem CVE-2025-54988. (NVD)
• GitHub Advisory (GHSA-f58c-gq56-vjjf) – szczegóły: przyczyna w tika-core, konsekwencje „partial patch”, wersje naprawione. (GitHub)
• Belgian CCB (rządowe CERT) – ostrzeżenie o eksfiltracji danych/SSRF i szerokim użyciu Tiki. (ccb.belgium.be)
• Strona projektu Apache Tika – ogólne info o wydaniach i bezpieczeństwie (w tym 3.2.2 jako najnowsza linia 3.x). (tika.apache.org)