Docling CVE-2026-105743: dokument może skierować żądanie do sieci wewnętrznej

CVE-2026-105743, opublikowany 5 października, opisuje obejście kontroli adresów w Docling. Ponowne rozwiązywanie DNS i różnice w interpretacji URL mogą kierować pobieranie zasobów do usług wewnętrznych. Ujawnienie odpowiedzi jest ograniczone do zawartości odczytanej jako obraz lub widocznej na zrzucie renderowanej strony.

Rekomendacja Breachroad na dziś: przejrzyj etap konwersji dokumentów w firmowym pipeline AI lub RAG. Ustal wersję parsera, źródła dokumentów i możliwość wykonywania połączeń sieciowych. Ocena samego modelu językowego nie odpowiada na pytanie, co robi infrastruktura przygotowująca jego dane.

Które konfiguracje wymagają sprawdzenia

Biuletyn projektu obejmuje Docling od 2.91.0 do wersji wcześniejszych niż 2.132.0, a docling-slim od 2.92.0 do wersji wcześniejszych niż 2.132.0. Problem wymaga enable_remote_fetch=True wraz z pobieraniem obrazów albo renderowaniem HTML. Domyślne enable_remote_fetch=False nie jest objęte opisanym scenariuszem. Poprawiona wersja obu pakietów to 2.132.0.

Nasza propozycja dla właściciela aplikacji: zapisz konfigurację faktycznie uruchomionego procesu, zamiast opierać się wyłącznie na domyślnych ustawieniach biblioteki. Sprawdź, czy kod aplikacji, profil przetwarzania lub integracja zmieniają opcje konwersji. Dokument przesłany przez klienta może przechodzić inną ścieżką niż materiały utrzymywane we własnym repozytorium.

Inwentaryzacja powinna połączyć komponent z usługą, właścicielem i kontem procesu. Przy każdej ścieżce ustal, czy pracownik może dostarczyć dowolny plik lub wskazać zewnętrzny materiał. Wynik „pakiet występuje” wymaga jeszcze odpowiedzi, jakie wejścia do niego docierają.

Popraw parser i ogranicz jego połączenia

Wydanie 2.132.0, dostępne od 1 października, zawiera zmianę sprawdzającą wszystkie rozwiązane adresy i ograniczającą zakres nagłówków pobierania do źródłowego originu. Powiąż aktualizację z obrazem lub pakietem faktycznie wdrożonym w usłudze.

Breachroad zaleca przygotować mapę dozwolonych połączeń parsera. Jeśli konwersja nie potrzebuje sieci, pozostaw pobieranie zdalne wyłączone. Jeżeli potrzebuje, zespół infrastruktury powinien ustalić dostępne cele i odseparować proces od usług, z których nie korzysta. Dodatkowo oceń konfigurację proxy: droga wyjścia z aplikacji powinna być znana i objęta kontrolą.

Aktualizacja zależności i ograniczenia sieciowe mają różne zadania. Pierwsza usuwa opisany błąd, drugie zmniejszają zakres zasobów osiągalnych przez proces. Przy wyjątku od aktualizacji wskaż osobę odpowiedzialną, termin oraz powód. Nie zamykaj zadania tylko dlatego, że reguła sieciowa została dodana do dokumentacji.

Sprawdź działanie na bezpiecznym przykładzie

Proponujemy test zgodności na syntetycznym dokumencie z zasobem zewnętrznym należącym do organizacji. Potwierdź, że aktualizacja nie psuje oczekiwanej konwersji i że blokady sieciowe działają zgodnie z uzgodnioną polityką. Sprawdzaj też rejestrowanie odrzuconych połączeń oraz identyfikację zadania, które je wywołało.

Nie wymaga to kierowania żądań do cudzej infrastruktury ani używania rzeczywistych danych klientów. Celem jest dowód, że wdrożona wersja i reguły odpowiadają decyzji zespołu. Zapisz wynik razem z identyfikatorem obrazu, datą i właścicielem sprawdzenia.

Przykład do omówienia z zespołem AI

Wyobraźmy sobie portal przyjmujący dokumenty do firmowej bazy wiedzy. W naszym przykładowym scenariuszu administrator odkrywa, że jeden profil konwersji pobiera ilustracje z internetu. Aktualizuje parser, uzgadnia dozwolone połączenia i dokumentuje, kto może zmieniać ten profil. Pracownicy dostają jasną zasadę zgłaszania materiałów, których konwersja została zatrzymana.

To propozycja procesu Breachroad, nie opis incydentu. Szerszy kontekst znajdziesz w przewodniku po bezpieczeństwie RAG. Na szkoleniu z cyberbezpieczeństwa i bezpiecznego AI dla organizacji możemy przećwiczyć ocenę źródeł dokumentów, granice integracji oraz podział odpowiedzialności między użytkownika, dewelopera i administratora.