Spring AI CVE-2026-59318: model mógł uruchomić nieudostępnione narzędzie

22 sierpnia rekord CVE-2026-59318 otrzymał kolejną aktualizację metadanych po publikacji oficjalnego komunikatu Spring 20 sierpnia i wpisu CVE dzień później. Podatność dotyczy wywoływania narzędzi w Spring AI. Lista funkcji udostępniona dla konkretnego żądania była pokazywana modelowi jako granica, ale w określonych warunkach warstwa wykonawcza mogła odnaleźć narzędzie z globalnego resolvera i uruchomić je, choć nie znajdowało się na liście bieżącego żądania.

To ważne rozróżnienie: model nie „zdobywa” nowej funkcji ani nie łamie zabezpieczeń Javy. Otrzymuje lub wytwarza nazwę wywołania, a framework podejmuje decyzję, czy tę nazwę rozwiązać. Jeśli dyspozytor korzysta z szerszego katalogu niż katalog ogłoszony modelowi, prezentacja capabilities przestaje być egzekwowaną polityką. Prompt injection może wtedy zamienić różnicę między tymi zbiorami w eskalację uprawnień.

Zakres i poprawione wersje

Spring wymienia jako podatne: 2.0.0, gałąź 1.1.0–1.1.8 oraz 1.0.0–1.0.9. Poprawka OSS znajduje się w 2.0.1. Dla klientów Enterprise Support udostępniono odpowiednio 2.0.0.1, 1.1.9 i 1.0.10. Advisory ocenia problem jako medium; wektor CVSS 3.1 ma wynik 6.5 i zakłada sieć, wysoką złożoność, niskie uprawnienia oraz interakcję użytkownika.

Nie należy jednak kopiować oceny bazowej bez kontekstu. Narzędzie tylko do odczytu publicznego katalogu i funkcja zatwierdzająca przelew mają zupełnie inny wpływ biznesowy. Istotne jest, które globalnie zarejestrowane callbacki istnieją w procesie, jakie mają poświadczenia, czy modyfikują stan oraz czy wymagają dodatkowej zgody poza modelem.

Samo posiadanie Spring AI w drzewie zależności nie dowodzi osiągalności. Trzeba potwierdzić użycie tool calling oraz DefaultToolCallingManager, sposób rejestracji resolverów i to, czy aplikacja zmienia zestaw funkcji per użytkownik, tenant, agent lub etap workflow. Jeżeli każdy request zawsze ma ten sam zestaw, różnica zbiorów może nie występować, ale aktualizacja nadal usuwa niebezpieczne założenie.

Dwie decyzje, które muszą być identyczne

System agentowy wykonuje co najmniej dwa kroki. Najpierw buduje opis narzędzi dla modelu: nazwy, parametry i przeznaczenie. Później odbiera wygenerowane wywołanie i mapuje nazwę na kod. Bezpieczny projekt wymaga, aby etap wykonania zaakceptował wyłącznie funkcję z niezmiennego zestawu zatwierdzonego dla tego samego żądania.

Globalny resolver bywa wygodny, ponieważ upraszcza rejestrację beanów i ponowne użycie funkcji. Nie powinien jednak działać jako fallback autoryzacyjny. To katalog implementacji, nie dowód prawa do wykonania. Podobny błąd występuje w API, gdy interfejs ukrywa przycisk, lecz backend nadal przyjmuje bezpośrednie żądanie. W AI dodatkowym problemem jest to, że niezaufany dokument może zasugerować modelowi nazwę ukrytej funkcji.

Granica musi być liczona po stronie deterministycznego kodu z tożsamości użytkownika, tenanta, celu operacji i aktualnego etapu. Model może zaproponować akcję, lecz nie powinien decydować o własnych uprawnieniach. Nazwa narzędzia jest wejściem nieufnym tak samo jak parametr HTTP.

Jak prompt injection wykorzystuje lukę semantyczną

Advisory wskazuje prompt injection jako drogę do nieogłoszonego wywołania. Instrukcja może pochodzić z dokumentu RAG, strony pobranej przez agenta, zgłoszenia klienta albo pola w bazie. Nie musi zmienić konfiguracji aplikacji. Wystarczy, że skłoni model do zwrócenia poprawnie sformatowanej nazwy funkcji, którą globalny resolver zna, a request nie powinien znać.

Nie każdy taki sygnał prowadzi do szkody. Dyspozytor może odrzucić nazwę, callback może wykonywać własną autoryzację, a operacja może wymagać zatwierdzenia człowieka. CVE pokazuje jednak, że nie wolno zakładać, iż brak funkcji w promptcie jest wystarczającą kontrolą. Prompt jest informacją dla modelu, a nie listą ACL dla serwera.

Inwentaryzacja ekspozycji

Zbuduj tabelę wszystkich callbacków dostępnych dla resolvera. Dla każdego zapisz właściciela, źródło rejestracji, wymagane role, tenant scope, używane sekrety, egress, efekt uboczny i sposób cofnięcia. Następnie porównaj ją z zestawami przekazywanymi w poszczególnych ścieżkach aplikacji. Najpilniejsze są narzędzia obecne globalnie, lecz celowo wycinane z części requestów.

Sprawdź finalny artefakt, nie tylko deklarację w pliku build. BOM, dependency management, prywatny starter i cache obrazu mogą utrzymać podatną wersję. W środowisku wielomodułowym potwierdź wersję na runtime oraz pochodzenie wszystkich instancji frameworka.

Przejrzyj również callbacki pod kątem obrony w głąb. Funkcja usuwająca rekord powinna ponownie zweryfikować principal i prawo do konkretnego obiektu. Argument zawierający tenantId nie może sam ustanawiać kontekstu tenanta. Poświadczenia serwisowe powinny mieć minimalny zakres, żeby błąd w dyspozytorze nie zamieniał się automatycznie w administrację całym środowiskiem.

Aktualizacja i test regresji

Najbezpieczniejszym działaniem jest przejście do odpowiadającej wersji poprawionej. Zbuduj świeży artefakt, zweryfikuj lockfile lub dependency tree i przeprowadź rollout canary. Testy muszą objąć legalne wywołania, brak narzędzia, błędną nazwę, powtórzenie requestu, równoległych tenantów oraz zmianę dozwolonego zestawu pomiędzy etapami rozmowy.

Test negatywny powinien użyć bezpiecznego callbacku testowego i sprawdzić, że funkcja zarejestrowana globalnie, ale niewystawiona dla żądania, zostaje odrzucona przed wykonaniem. Nie testuj produkcji funkcją o realnym skutku. W logu powinien pozostać jednoznaczny powód odmowy, identyfikator polityki i requestu, lecz nie pełny prompt ani sekretne argumenty.

Jeżeli aktualizacja musi czekać, usuń z procesu niepotrzebne globalne narzędzia, rozdziel agentów o różnych poziomach zaufania na osobne usługi i wymuś autoryzację wewnątrz callbacków. Approval dla operacji wysokiego ryzyka ogranicza wpływ, ale nie naprawia resolvera. Filtrowanie promptów także nie stanowi trwałej mitygacji.

Detekcja i odpowiedź

Rejestruj zbiór advertisedToolIds, wybraną funkcję, wynik decyzji autoryzacyjnej, principal, tenant, model, źródła kontekstu i skutek operacji. Wrażliwe argumenty tokenizuj lub redaguj. Alert powinien uruchamiać się, gdy wybrana nazwa nie należy do zbioru ogłoszonego, nawet jeśli framework ostatecznie ją odrzucił. To cenna telemetria prompt injection i błędów integracji.

W historycznych logach szukaj wywołań narzędzi niespójnych z typem agenta lub etapem procesu, zwłaszcza operacji administracyjnych po przetworzeniu zewnętrznej treści. Samo wystąpienie nie dowodzi wykorzystania CVE: zestaw mógł zostać zmieniony legalnie, a logowanie może nie oddawać snapshotu requestu. Potwierdzaj korelacją z wersją, konfiguracją i efektem w systemie docelowym.

Jeżeli znajdziesz nieuprawnione wykonanie, zatrzymaj dany workflow, zachowaj ślady, oceń skutki w systemie narzędzia i unieważnij tylko faktycznie narażone poświadczenia. Aktualizacja frameworka zamyka drogę dispatchu, lecz nie cofa wcześniejszych zmian.

Właściciel polityki musi być poza promptem

Zespół powinien jednoznacznie wskazać komponent odpowiedzialny za decyzję: policy engine, warstwa serwisowa lub callback. Polityka nie może istnieć wyłącznie jako zdanie w system prompt, ponieważ ten sam kanał przenosi niezaufany kontekst i wynik modelu. Wersjonuj reguły, zapisuj identyfikator wersji przy decyzji i testuj je niezależnie od modelu.

Zmiana promptu, modelu lub dostawcy nie powinna rozszerzać uprawnień. Jeżeli agent przechodzi z trybu analizy do wykonania, utwórz nowy, jawny snapshot capabilities i wymagaj ponownej oceny tożsamości. Dzięki temu zespół potrafi udowodnić, dlaczego konkretna funkcja była dostępna w danym momencie, zamiast rekonstruować intencję z tekstu rozmowy.

Fakty producenta i wnioski Breachroad

Zakres wersji, mechanizm globalnego fallbacku, możliwość nieogłoszonego dispatchu, wektor CVSS i poprawione wydania pochodzą z oficjalnego advisory Spring. Producent nie informuje tam o aktywnej eksploatacji. Data 22 sierpnia odnosi się do dzisiejszej aktualizacji publicznego rekordu; pierwsza publikacja Spring nastąpiła 20 sierpnia.

Model snapshotu capabilities, autoryzacja w callbacku, rozdzielenie usług, telemetryka i procedura incident response są wnioskami Breachroad. Szkolenie z bezpiecznego wdrażania AI pomaga zespołom rozdzielić decyzję modelu od uprawnienia, a audyt bezpieczeństwa AI może prześledzić resolver, callbacki, tożsamości, sekrety i egress.

Źródła

• Spring — CVE-2026-59318: unadvertised tool dispatch
• NVD — CVE-2026-59318
• Spring AI — dokumentacja tool calling