Atak na Marimo z użyciem RCE: przejęcie bastionu SSH w osiem sekund

Wprowadzenie do problemu / definicja

Marimo, środowisko notebookowe dla Pythona, znalazło się w centrum uwagi po ujawnieniu krytycznej podatności typu remote code execution oznaczonej jako CVE-2026-39987. Opisany incydent pokazuje, że podatna instancja wystawiona do Internetu może stać się punktem wejścia do znacznie szerszej infrastruktury, zwłaszcza jeśli ma dostęp do sekretów, ról chmurowych lub zasobów administracyjnych.

Najważniejszy wniosek z analizowanego przypadku jest prosty: szybkie przejęcie środowiska nie wymagało zaawansowanego agenta AI ani rozbudowanego publicznego frameworka ofensywnego. Wystarczył doświadczony operator, dobrze przygotowany łańcuch działań i wykorzystanie błędów architektonicznych po stronie ofiary.

W skrócie

Atakujący wykorzystał podatność CVE-2026-39987 w Marimo do uzyskania nieautoryzowanej powłoki.
Następnie pozyskał poświadczenia z naruszonej instancji i odwołał się do AWS Secrets Manager.
Z menedżera sekretów pobrano klucz prywatny użyty do logowania na bastion SSH.
Przejście od połączenia z terminalem WebSocket do uwierzytelnienia na bastionie zajęło zaledwie osiem sekund.
W obserwowanej kampanii nie stwierdzono użycia publicznych frameworków ofensywnych ani wsparcia agenta AI.

Kontekst / historia

CVE-2026-39987 została opisana jako krytyczna luka pre-auth RCE dotycząca terminala WebSocket w Marimo. Tego typu podatności są szczególnie niebezpieczne w środowiskach notebookowych, ponieważ często łączą publiczną ekspozycję z dostępem do wrażliwych danych operacyjnych.

Już wcześniejsze analizy wskazywały, że internetowo dostępne notebooki stanowią atrakcyjny cel dla napastników. Mogą przechowywać tokeny API, dane uwierzytelniające do chmury, sekrety aplikacyjne, a także zapewniać ścieżkę do segmentów wewnętrznych. W poprzednich kampaniach ta sama podatność była łączona zarówno z szybką automatyzacją eksploatacji, jak i wdrażaniem kolejnych komponentów złośliwej infrastruktury po uzyskaniu dostępu.

Najnowszy incydent jest jednak istotny z innego powodu. Pokazuje, że „prędkość maszynowa” nie musi oznaczać użycia AI. Odpowiednio przygotowany operator może działać równie szybko, a jednocześnie bardziej elastycznie reagować na warunki panujące w naruszonym środowisku.

Analiza techniczna

Punktem wejścia był wystawiony endpoint WebSocket terminala w podatnej instancji Marimo. Luka umożliwiała uzyskanie interaktywnej powłoki bez wcześniejszego logowania, co w praktyce dawało natychmiastowy dostęp do środowiska uruchomieniowego aplikacji.

Po uzyskaniu pierwszego dostępu operator przeszedł do etapu zbierania poświadczeń. Z naruszonej instancji pobrano dane uwierzytelniające, które następnie posłużyły do odczytu sekretów z AWS Secrets Manager. To klasyczny przykład pivotu z poziomu pojedynczego workloadu do warstwy tożsamości i zarządzania sekretami w chmurze.

Kolejny etap obejmował pobranie klucza prywatnego i wykorzystanie go do logowania na serwerze bastionowym. Szczególnie alarmujące jest tempo całego łańcucha: od otwarcia połączenia WebSocket do uwierzytelnienia na bastionie SSH minęło jedynie osiem sekund. Według ustaleń badaczy atak został zautomatyzowany przy użyciu własnych skryptów Pythona uruchamianych w tle, które wykonywały pobranie sekretu, zapis klucza i inicjację połączenia SSH w jednym przebiegu.

W dalszej fazie sesji operator miał wykonywać setki poleceń interaktywnych bez korzystania z powszechnie rozpoznawalnych narzędzi ofensywnych. Z perspektywy detekcji oznacza to ograniczoną skuteczność prostych wskaźników kompromitacji i większe znaczenie analiz behawioralnych oraz korelacji zdarzeń między aplikacją, hostem i usługami chmurowymi.

Konsekwencje / ryzyko

Największe ryzyko wynika z błyskawicznego przejścia od podatnej usługi do zasobów o wyższym poziomie zaufania. Jeśli notebook ma dostęp do ról IAM, sekretów, kluczy SSH lub sieci administracyjnej, jego kompromitacja może w bardzo krótkim czasie doprowadzić do ruchu bocznego i naruszenia kolejnych systemów.

Bastion SSH jest w tym kontekście zasobem szczególnie wrażliwym. Często stanowi on bramę do środowisk produkcyjnych, hostów zarządzających i segmentów niedostępnych publicznie. Uzyskanie dostępu do takiego punktu pośredniczącego może diametralnie zwiększyć skalę incydentu.

Przypadek Marimo pokazuje też szerszy problem organizacyjny. Narzędzia deweloperskie, analityczne i data science bywają wystawiane do Internetu bez silnej segmentacji, z nadmiernymi uprawnieniami i bez odpowiedniej ochrony dostępu. W takim modelu bezpieczeństwa pojedyncza luka RCE może szybko przerodzić się w pełnoskalowe naruszenie środowiska chmurowego i wewnętrznej infrastruktury.

Rekomendacje

W pierwszej kolejności organizacje powinny zidentyfikować wszystkie publicznie dostępne instancje Marimo i pilnie zweryfikować ich stan podatności. Jeśli usługa nie musi być osiągalna z Internetu, należy ją ukryć za VPN, reverse proxy z silnym uwierzytelnianiem albo przenieść do segmentu prywatnego.

Równie istotne jest ograniczenie uprawnień. Notebooki i środowiska robocze nie powinny mieć szerokiego dostępu do menedżerów sekretów, ról chmurowych ani kluczy umożliwiających logowanie na bastiony i hosty administracyjne. W praktyce oznacza to wdrożenie zasady najmniejszych uprawnień, separację ról oraz rotację wszystkich sekretów, które mogły zostać ujawnione.

Monitorować nowe i nietypowe połączenia do terminali WebSocket.
Wykrywać uruchamianie powłok i interpreterów z kontekstu notebooka.
Alertować na nietypowe odwołania do AWS Secrets Manager i podobnych usług.
Śledzić zapis kluczy prywatnych na dysku tymczasowym lub w katalogach roboczych.
Analizować połączenia SSH wychodzące z instancji aplikacyjnych do bastionów.
Korelować krótkie sekwencje zdarzeń obejmujące wykonanie kodu, pobranie sekretu i ruch boczny.

W środowiskach cloud-native dodatkową wartość przyniosą kontrole runtime, telemetria eBPF oraz korelacja logów z warstwy IAM. Organizacje powinny również przeprowadzić przegląd ekspozycji wszystkich notebooków i narzędzi AI/ML, ponieważ coraz częściej są one traktowane przez napastników jako wygodny punkt wejścia do infrastruktury.

Podsumowanie

Incydent związany z CVE-2026-39987 to ważne ostrzeżenie dla zespołów bezpieczeństwa. Pokazuje, że krytyczna luka w internetowo dostępnym notebooku może prowadzić nie tylko do lokalnego wykonania kodu, lecz także do błyskawicznego przejęcia zasobów chmurowych i wewnętrznych systemów.

Osiągnięcie bastionu SSH w osiem sekund potwierdza, że szybkość działania nie jest wyłącznie domeną ataków wspieranych przez AI. Kluczowe działania obronne to redukcja ekspozycji usług, szybkie łatanie, ścisłe ograniczanie uprawnień, rotacja sekretów oraz detekcja oparta na analizie całego łańcucha ataku.