Spring AI: PDF może przepełnić stos, a lokalny napastnik podmienić model ONNX

Dwa rekordy Spring AI pokazują dwie różne granice bezpieczeństwa pipeline’u: strukturę dokumentu i pochodzenie modelu. CVE-2026-47851 pozwala plikowi PDF z głęboko zagnieżdżonym lub cyklicznym spisem treści wywołać StackOverflowError w wątku ingest. CVE-2026-47852 pozwala lokalnemu użytkownikowi na współdzielonym hoście uprzedzić proces, utworzyć przewidywalną ścieżkę cache i umieścić w niej podmieniony model ONNX.

Oba problemy otrzymały CVSS 3.1 7,5 (High) i dotyczą Spring AI 2.0.0, 1.1.0–1.1.8 oraz 1.0.0–1.0.9. Biuletyny producenta są datowane na 20 sierpnia, natomiast rekordy CVE opublikowano 26 sierpnia o 23:28 UTC, czyli 27 sierpnia czasu polskiego. Otwartym wydaniem naprawczym jest 2.0.1; Spring wymienia też poprawione wersje 2.0.0.1, 1.1.9 i 1.0.10 w kanałach Enterprise Support.

PDF jest grafem wejściowym, nie tylko tekstem

Aplikacja RAG często traktuje PDF jak pojemnik na strony, z których wystarczy wyciągnąć tekst. Format może jednak zawierać złożone drzewa obiektów, odwołania, formularze, załączniki i outline reprezentujący spis treści. Parser musi przejść strukturę, zanim powstaną fragmenty tekstu i embeddingi. Atak może więc nastąpić przed właściwą logiką AI.

CVE-2026-47851 dotyczy nieograniczonej rekurencji po outline. Normalny spis ma strukturę drzewa, ale nieufny dokument może wymusić skrajną głębokość albo cykl. Każde wywołanie rekurencyjne zużywa ramkę stosu JVM. Gdy limit zostanie wyczerpany, powstaje StackOverflowError, który przerywa wątek przetwarzający dokument.

CVSS zakłada atak sieciowy bez uprawnień i interakcji, lecz osiągalność zależy od aplikacji. Sama biblioteka nie tworzy publicznego uploadu. Podatny jest system, który przekazuje kontrolowany PDF do Spring AI PDF Document Reader: portal do budowy bazy wiedzy, skrzynka ingestująca załączniki, crawler albo automatyczny pipeline dokumentów.

Dlaczego błąd jednego wątku może zatrzymać usługę

Skutek techniczny opisany przez Spring to błąd w wątku ingest. W architekturze z osobną kolejką i dobrze izolowanym workerem jeden dokument może zakończyć pojedynczy task. W źle zaprojektowanym systemie ta sama wiadomość wraca z kolejki, powoduje pętlę retry, zużywa wszystkie workery i blokuje legalne dokumenty. Jeśli parser działa w procesie API, błąd może zmniejszyć pulę dostępnych wątków lub doprowadzić do restartu.

Dlatego odporność nie kończy się na patchu. Pipeline powinien mieć limit rozmiaru, liczby obiektów, głębokości outline, czasu CPU i liczby retry. Dokument powodujący deterministyczny błąd musi trafić do dead-letter queue, a nie wracać bez końca. Parser może działać w osobnym procesie lub kontenerze z limitem pamięci i bez sekretów potrzebnych dopiero na późniejszym etapie.

Monitoring powinien rozróżniać błąd dokumentu od awarii platformy. Alarmuj na StackOverflowError, wielokrotną porażkę tego samego hasha, wzrost wieku kolejki i spadek throughputu. Hash pozwala zablokować identyczny plik, ale nie zastępuje limitów strukturalnych: wiele różnych dokumentów może reprezentować tę samą złośliwą klasę grafu.

ONNX w cache jest kodem zaufania pipeline’u

Druga luka ma inne wymagania. CVE-2026-47852 zakłada lokalnego napastnika na hoście wielu użytkowników. Spring AI używało deterministycznej lokalizacji cache. Jeżeli atakujący mógł utworzyć katalog lub plik przed procesem aplikacji, mógł posadzić tam złośliwy model ONNX, który aplikacja później uznawała za własny artefakt.

ONNX jest formatem grafu obliczeniowego, nie klasycznym wykonywalnym ELF czy JAR. Podmiana nadal narusza integralność. Model może generować celowo błędne embeddingi, klasyfikacje lub wyniki, zużywać nadmierne zasoby albo wykorzystać osobną podatność runtime’u ONNX. Advisory opisuje podmianę modelu, a nie potwierdzone arbitralne wykonanie kodu; nie należy automatycznie zamieniać impactu integralności w RCE.

W pipeline’ie embeddingów podmieniony model może cicho zmienić przestrzeń wektorową. Nowe dokumenty będą indeksowane innymi reprezentacjami niż stare, retrieval pogorszy się, a wyniki mogą faworyzować lub ukrywać określone treści. W klasyfikatorze bezpieczeństwa napastnik może próbować obniżyć wykrywalność wybranych danych. To atak na zachowanie systemu, nawet jeśli host nie zostaje przejęty.

Dlaczego przewidywalna nazwa katalogu jest groźna

Ścieżka cache sama może być deterministyczna, jeśli katalog nadrzędny ma właściwego właściciela, prawa i atomowy proces tworzenia. Problem pojawia się na współdzielonym hoście, gdy niezaufany użytkownik może uprzedzić proces o wyższych lub innych uprawnieniach. Jest to rodzina pre-creation i symlink attacks: aplikacja zakłada, że znana nazwa identyfikuje jej zasób, choć namespace kontrolował ktoś inny.

Bezpieczny cache powinien powstawać w katalogu prywatnym dla konta usługi, z restrykcyjnym umask, bez podążania za linkami i z atomowym tworzeniem. Pobrany model powinien być przypięty do wersji i skrótu kryptograficznego. Weryfikacja hasha musi nastąpić przed otwarciem modelu przez runtime, a manifest powinien pochodzić z innego, zaufanego kanału niż sam plik.

Kontener nie gwarantuje ochrony, jeśli kilka workloadów współdzieli writable volume albo hostPath. Serverless i Kubernetes często zmniejszają ryzyko lokalnego użytkownika, ale wspólny cache modeli, notebook hub, host CI lub maszyna laboratoryjna ponownie tworzą granicę wielu tenantów. Trzeba ocenić skuteczne mounty i UID, a nie etykietę platformy.

Co zaktualizować

Spring wskazuje jako naprawiony cel OSS Spring AI 2.0.1. Organizacje na komercyjnie wspieranych liniach mają również 2.0.0.1, 1.1.9 i 1.0.10. Nie należy wnioskować wersji wyłącznie z parent POM lub Spring Boot BOM. Sprawdź rozwiązaną wersję modułów Spring AI w dependency tree, SBOM i uruchomionym artefakcie.

Po aktualizacji przebuduj obrazy bez zachowania starej warstwy cache i usuń niezaufane lokalne artefakty zgodnie z kontrolowaną procedurą. Nie kasuj globalnie katalogów na współdzielonym hoście bez ustalenia właścicieli. Najpierw zidentyfikuj ścieżki używane przez proces, zachowaj podejrzane pliki do analizy i odtwórz cache z przypiętego źródła.

Dla PDF wykonaj test legalnych dokumentów z rozbudowanym spisem, dokumentu bez outline, dużego pliku i kontrolowanego przypadku przekraczającego limit. Dla ONNX potwierdź ownera katalogu, prawa, zachowanie przy istniejącym pliku o złym hashu i pobranie po czystym starcie. Test ma dowieść zarówno bezpieczeństwa, jak i tego, że poprawka nie zrywa legalnego cold startu.

Dochodzenie i rotacja

Jeśli wystąpiły błędy stosu, zachowaj hash dokumentu, metadata uploadu, identyfikator zadania i logi retry. Nie otwieraj nieznanego PDF w uprzywilejowanej stacji analityka. Użyj izolowanego parsera i narzędzi statycznych. Sprawdź, czy zdarzenie wywołało tylko błąd taska, czy także utratę kolejki, restart procesu lub opóźnienie innych tenantów.

Dla cache ONNX porównaj hash i pochodzenie każdego modelu z zatwierdzonym manifestem, sprawdź właściciela, czasy utworzenia i linki symboliczne. Ustal, które procesy załadowały artefakt i jakie wyniki wytworzyły. Jeśli model wpływał na decyzje bezpieczeństwa lub dane klientów, incydent może wymagać ponownego przeliczenia indeksów, klasyfikacji albo raportów.

Nie ma automatycznej potrzeby rotacji wszystkich sekretów po samym wykryciu niezgodnego modelu. Rotacja jest uzasadniona, gdy analiza wykaże wykorzystanie podatności runtime’u, odczyt credentiali albo szerszą kompromitację hosta. W przeciwnym razie priorytetem jest przywrócenie integralności artefaktów i wyników.

Wspólna lekcja: ingest to powierzchnia wykonawcza

Obie luki występują przed wywołaniem LLM. Dokument steruje zachowaniem parsera, a plik modelu steruje obliczeniami runtime’u. Granica AI zaczyna się więc na uploadzie i cache, a nie na promptcie. Skanowanie prompt injection nie wykryje cyklicznego outline ani lokalnej podmiany ONNX.

Manifest pipeline’u powinien obejmować źródło, hash, format, parser, wersję runtime’u, limity i ownera każdego artefaktu. Telemetria powinna łączyć dokument z jego kolejnymi reprezentacjami: tekstem, chunkami, embeddingami i wpisem w vector store. Dzięki temu po incydencie można ustalić, które wyniki wymagają odbudowy.

Fakty źródłowe i wnioski Breachroad

Mechanizm rekurencji PDF, lokalnej podmiany ONNX, zakres wersji, oceny CVSS i poprawione wydania pochodzą z biuletynów Spring oraz rekordów CVE. Producent nie podaje aktywnej eksploatacji. Skutki dla RAG i embeddingów, izolacja workerów, manifest artefaktów, telemetria oraz procedury dochodzenia są wnioskami Breachroad.

Szkolenia z bezpieczeństwa AI, RAG i MLOps pomagają zespołom projektować bezpieczny ingest, a audyty aplikacji i API mogą ocenić upload dokumentów, cache modeli, izolację workerów i integralność artefaktów.

Źródła

• Spring AI — CVE-2026-47851
• Spring AI — CVE-2026-47852
• Spring AI — repozytorium projektu
• NVD — CVE-2026-47851
• NVD — CVE-2026-47852