Spring AI CVE-2026-59279: sesje MCP bez limitu wyczerpują pamięć

21 sierpnia CVE-2026-59279 trafiło do publicznych baz podatności po komunikacie Spring opublikowanym dzień wcześniej. Problem dotyczy Spring AI 2.0.0 i transportu serwera MCP Streamable HTTP w wariantach WebFlux oraz WebMvc. Implementacja przechowuje sesje bez ograniczenia ich liczby, a domyślnie nie wymaga uwierzytelnienia klienta. Zdalny napastnik może wielokrotnie inicjalizować nowe sesje, stopniowo zużyć pamięć i odebrać usługę wszystkim legalnym agentom.

To CVSS 7.5 i czysty wpływ na dostępność. Nie ma podstaw, aby dopisywać odczyt promptów, wykonanie narzędzi lub przejęcie serwera. Mimo to DoS na warstwie MCP może zatrzymać proces biznesowy, który opiera się na agentach, oraz ukryć inne działania w szumie restartów.

Gdzie dokładnie jest granica

MCP Streamable HTTP pozwala klientowi wysłać initialize, otrzymać identyfikator sesji i kontynuować wymianę przez HTTP. Serwer musi zachować stan, aby powiązać kolejne żądania z capabilities, transportem i lifecycle klienta. Jeżeli każda inicjalizacja tworzy trwały rekord, a nie istnieją limit, TTL ani obowiązkowa tożsamość, anonimowy klient może produkować stan szybciej, niż serwer go usuwa.

WebFlux i WebMvc różnią się modelem wykonania, ale advisory obejmuje oba warianty. Reactive stack nie rozwiązuje problemu semantycznego: nieograniczona mapa sesji nadal rośnie. Podobnie autoscaling nie usuwa podatności. Może nawet zwiększyć koszt, bo ruch tworzy kolejne instancje i powtarza alokację.

Zakres wersji i poprawka

Spring wskazuje dokładnie Spring AI 2.0.0 jako wersję podatną. Publiczna poprawka OSS znajduje się w 2.0.1. Dla klientów Enterprise Support dostępna jest wersja 2.0.0.1. Producent stwierdza, że po przejściu do odpowiadającej wersji naprawionej nie są potrzebne dalsze kroki mitygacyjne dla samego CVE.

Administrator powinien jednak potwierdzić rzeczywistą wersję w dependency tree oraz obrazie. Spring Boot BOM, dependency management i cache Gradle/Maven mogą spowodować, że kod źródłowy deklaruje inną wersję niż finalny JAR. W środowisku z wieloma usługami wyszukaj również prywatne startery kopiujące konfigurację transportu.

Dlaczego reverse proxy nie wystarcza

Rate limiting na brzegu może ograniczyć szybkość tworzenia sesji, ale nie zwalnia istniejących rekordów. Jeśli limit dopuszcza tysiąc inicjalizacji dziennie, a stan nie ma TTL, pamięć nadal rośnie. Limit request body także nie pomaga, bo payload inicjalizacji nie musi być duży. WAF może rozpoznać endpoint, lecz semantycznie poprawne initialize trudno odróżnić od legalnego klienta bez tożsamości i budżetu.

Najlepszą kontrolą jest wersja naprawiona. Dodatkowo architektura powinna egzekwować uwierzytelnienie przed tworzeniem trwałego stanu, maksymalną liczbę aktywnych sesji per principal i globalnie, czas bezczynności, absolutny czas życia oraz atomowe usunięcie po błędzie lub zamknięciu.

Jak ocenić ekspozycję

Ustal, czy aplikacja rzeczywiście uruchamia MCP server transport, czy tylko klienta Spring AI. Sam dependency nie oznacza osiągalnego endpointu. Sprawdź WebMvc/WebFlux routes, reverse proxy, ingress, security chain i reguły sieciowe. Serwer dostępny tylko z loopback ma inne ryzyko niż endpoint opublikowany przez publiczny load balancer, ale host lokalny nadal może być współdzielony z niezaufanym procesem.

Zbierz metryki: liczba utworzonych i aktywnych sesji, tempo initialize, sesje per adres lub principal, czas ostatniej aktywności, heap occupancy, GC pause, liczba restartów i status endpointu. Jeżeli aplikacja nie eksportuje session count, dodaj tę obserwowalność po aktualizacji jako kontrolę operacyjną.

Bezpieczny plan wdrożenia

W staging uruchom tę samą konfigurację Spring Boot, reverse proxy i autoryzacji. Zaktualizuj do 2.0.1 lub wspieranej wersji Enterprise, zbuduj świeży artefakt i sprawdź SBOM. Wykonaj testy kompatybilności klientów MCP: inicjalizacja, ponowne połączenie, zakończenie, timeout, wiele legalnych sesji oraz utrata sieci.

Negatywny test powinien potwierdzić, że serwer ogranicza zasoby i odzyskuje pamięć, ale nie powinien odtwarzać masowego DoS na środowisku produkcyjnym. Obserwuj heap i session count podczas bezpiecznej, małej serii przerwanych inicjalizacji. Po wdrożeniu canary porównaj tempo GC, latency oraz błędy klientów.

Jeżeli update musi czekać, zamknij endpoint za uwierzytelnionym gateway, ogranicz źródła sieciowe i wprowadź restrykcyjny rate limit initialize. Restart z progiem pamięci może zapewnić chwilową dostępność, lecz powoduje utratę legalnych sesji i nie jest trwałą mitygacją. Nie zwiększaj po prostu heapu: wydłuża czas do awarii i zwiększa koszt recovery.

Hunting i odpowiedź na incydent dostępności

Szukaj wzrostu nowych session IDs bez odpowiadającego ruchu narzędzi, wielu inicjalizacji bez kontynuacji, równomiernego przyrostu heapu i pełnych GC bez uwolnienia pamięci. Źródłowy adres IP może reprezentować NAT lub proxy, dlatego koreluj X-Forwarded-For tylko wtedy, gdy pochodzi z zaufanego ingressu.

Heap dump może potwierdzić dominację obiektów sesji, ale zawiera wrażliwe dane. Zabezpiecz go jak artefakt incydentu i ogranicz dostęp. Logi restartów, OOMKill, pod events i load balancer 5xx pomagają zbudować linię czasu. Sam wzrost sesji nie dowodzi złośliwego działania; wadliwy klient z agresywnym reconnectem może wywołać ten sam efekt.

Po aktualizacji rozważ wygaszenie istniejących sesji i kontrolowany restart, jeśli stary proces zachował nagromadzony stan. Poinformuj właścicieli agentów o reconnect. Nie rotuj tokenów ani sekretów bez dowodu, ponieważ CVE opisuje dostępność, nie ujawnienie danych.

MCP jako publiczne API, nie „lokalna wtyczka”

Popularność MCP sprawia, że komponenty projektowane jako lokalne zaczynają działać w klastrach i przez load balancery. Każdy serwer MCP powinien mieć taki sam threat model jak API: tożsamość, autoryzację per narzędzie, budżet zasobów, walidację schematu, egress policy, audit log i procedurę unieważniania.

Lifecycle sesji jest częścią bezpieczeństwa. Tworzenie stanu przed auth, brak TTL i brak limitu per tenant to niezależne zapachy architektoniczne nawet po naprawie jednego CVE. Testy chaos i load powinny uwzględniać klienta, który nigdy nie zamyka sesji, wielokrotnie reconnectuje i znika w połowie inicjalizacji.

Jak ustalić właściwy budżet

Limit nie powinien być przypadkową liczbą. Policz maksymalną liczbę równoległych agentów, legalny burst po restarcie, pamięć przypadającą na sesję i czas potrzebny klientowi na reconnect. Zarezerwuj margines, ale ustaw alert dużo przed twardym progiem. Per-tenant limit zapobiega sytuacji, w której jeden dział odbiera zasoby pozostałym.

Obsługa odrzucenia też wymaga projektu. Serwer powinien zwrócić kontrolowany status i wskazówkę retry, a klient zastosować exponential backoff z jitterem. Bez tego poprawnie działający limit może wywołać reconnect storm, który utrzyma usługę w stanie przeciążenia po zakończeniu ataku.

Fakty producenta i wnioski Breachroad

Zakres Spring AI 2.0.0, WebFlux/WebMvc, brak limitu, domyślny brak auth, CVSS oraz wersje 2.0.1 i 2.0.0.1 pochodzą z oficjalnego advisory. Spring informuje, że problem wykryto wewnętrznie i nie podaje aktywnej eksploatacji.

Limity per principal, telemetry, canary, hunting i model MCP jako publicznego API są wnioskami Breachroad. Szkolenia bezpieczeństwa AI pomagają deweloperom i SOC uzgodnić te granice, a audyt bezpieczeństwa AI może zweryfikować transport, auth, lifecycle, narzędzia i egress.