8 kwietnia 2026 roku twórcy Marimo opublikowali ostrzeżenie o krytycznej podatności w swoim narzędziu. Napisali dokładnie, gdzie leży problem, dlaczego tam leży i co przez to jest możliwe. Nie opublikowali żadnego gotowego kodu demonstrującego atak — bo po co, skoro opis wystarczał w zupełności.
Niecałe dziesięć godzin później ktoś połączył się z podatnym punktem końcowym w środowisku-pułapce Sysdig i w ciągu trzech minut wyciągnął klucze dostępowe do chmury.
Czym jest Marimo i dlaczego ma klucze do wszystkiego
Marimo to reaktywny notatnik programistyczny dla Pythona — alternatywa dla Jupyter Notebooks, popularna wśród badaczy danych, inżynierów uczenia maszynowego i deweloperów budujących dashboardy analityczne. Narzędzie liczy około dwudziestu tysięcy gwiazdek na GitHubie: nie jest gigantyczną platformą, ale jest dokładnie tym rodzajem oprogramowania, które trafia do środowisk zawierających dane o dużej wartości. Połączenia z bazami danych, klucze do API modeli językowych, dane dostępowe do chmury, tokeny produkcyjne — to wszystko siedzi w środowisku, w którym działa Marimo.
Typowe wdrożenie Marimo uruchamiane jest w kontenerach Dockera, często z uprawnieniami roota, z dostępem do sieci hosta i systemu plików. Wiele instancji trafia na GPU w chmurze lub na przestrzenie robocze dostępne dla całego zespołu. Innymi słowy: to narzędzie, które z założenia ma dostęp do wielu rzeczy naraz. Podatność w nim nie oznacza wycieku jednego pliku — oznacza dostęp do całego środowiska pracy.
Gdzie leżała luka
Marimo udostępnia wbudowany terminal, który pozwala użytkownikom uruchamiać polecenia systemowe bez wychodzenia z notatnika. Terminal ten działa przez połączenie WebSocket pod adresem /terminal/ws.
Problem polega na tym, że ten konkretny punkt końcowy nie sprawdzał tożsamości łączącego się klienta. Inne punkty końcowe Marimo — jak /ws — wywołują funkcję validate_auth() przy każdym połączeniu. Terminal pomijał ten krok, sprawdzając tylko tryb uruchomienia i wsparcie platformy. Efekt: każdy, kto mógł nawiązać połączenie sieciowe z portem Marimo, dostawał pełną interaktywną powłokę systemową.
Nie trzeba było żadnego hasła. Żadnego tokenu. Żadnej sesji. Jedno połączenie — i terminal odpowiadał tak samo, jakby siedziało się przy klawiaturze maszyny.
CVE-2026-39987, wynik CVSS 9.3.
Dziewięć godzin i czterdzieści jeden minut
Sysdig prowadził sieć środowisk-pułapek monitorujących aktywność po ogłoszeniu podatności. Pierwszą próbę ataku zarejestrowali po 9 godzinach i 41 minutach od opublikowania ostrzeżenia. W momencie tego ataku nie istniał żaden publicznie dostępny gotowy kod demonstrujący podatność.
Atakujący zbudował działający mechanizm ataku wyłącznie na podstawie opisu w samym ostrzeżeniu. Połączył się z /terminal/ws, uruchomił kilka poleceń rozpoznawczych — przeglądanie katalogów, odczyt pliku .env — i w ciągu trzech minut wyciągnął klucze dostępowe AWS oraz inne zmienne środowiskowe.
W ciągu pierwszych dwunastu godzin po ogłoszeniu ponad sto dwadzieścia pięć adresów IP przeprowadziło rozpoznanie. Tylko jeden przeszedł do faktycznej eksploitacji. Ale ten jeden nie potrzebował gotowego kodu. Wystarczył opis.
Podatność, którą można zrozumieć z opisu
To jest istota tej historii i to, co odróżnia ją od wielu innych przypadków eksploitacji wkrótce po ogłoszeniu.
W większości podatności jest pewna odległość między opisem a działającym atakiem. Opis mówi, że "istnieje możliwość przepełnienia bufora w funkcji X przy określonych danych wejściowych" — ale żeby z tego wyciągnąć działający atak, trzeba rozumieć architekturę pamięci, znać środowisko, przetestować różne warianty ładunku. To zajmuje czas. Na tym czasie opiera się tradycyjny model: ogłaszasz podatność, dajesz administratorom okno na łatkowanie, zanim ktoś zbuduje działający atak.
W przypadku Marimo to okno nie istniało, bo sama podatność była trywialna w eksploitacji. Terminal WebSocket bez uwierzytelnienia oznacza: połącz się, pisz polecenia, odbieraj wyniki. Nie trzeba żadnego ładunku, żadnego kodowania, żadnej precyzji. Ostrzeżenie opisało dokładnie, który punkt końcowy jest podatny i dlaczego. Resztę można było wywnioskować w ciągu minut.
Sysdig zestawia to z wcześniejszym przypadkiem Langflow (CVE-2026-33017) — tam eksploitacja nastąpiła po dwudziestu godzinach, też bez publicznego kodu demonstracyjnego. Marimo: niecałe dziesięć. Tendencja jest czytelna.
Niszowość nie chroni
Warto zwrócić uwagę na skalę narzędzia, które zostało zaatakowane. Marimo ma około dwudziestu tysięcy gwiazdek na GitHubie. To ułamek tego, czym są Langflow (ponad sto czterdzieści tysięcy) czy n8n (ponad siedemdziesiąt pięć tysięcy) — platformy, które historycznie przyciągały masowe kampanie skanujące. Dwa lata temu można było zakładać, że podatność w niszowym narzędziu ma jakieś naturalne opóźnienie zanim ktoś w ogóle zwróci na nią uwagę.
To założenie przestało być słuszne. Sysdig wprost wskazuje, że atakujący monitorują źródła informacji o podatnościach szeroko — nie tylko dla głośnych platform — i potrafią w ciągu kilku godzin zbudować działający atak na podstawie samego opisu technicznego. Zdolność do szybkiej analizy ostrzeżeń i budowania ataków bez gotowego kodu demonstracyjnego wskazuje na wspomaganie narzędziami AI.
Jeśli prowadzisz niszowe narzędzie z poważną podatnością, nie masz już luksusowej anonimowości. Masz może kilka godzin.
Środowisko programistyczne jako cel sam w sobie
Jest jeszcze jedna warstwa tej historii, którą warto wyciągnąć. Marimo nie jest systemem produkcyjnym w klasycznym sensie. To narzędzie deweloperskie. Ale właśnie dlatego jest tak wartościowym celem.
Środowiska notatnikowe są skonfigurowane z wszystkim, czego deweloper potrzebuje do pracy: połączenia z bazami danych, klucze do API modeli językowych, dane dostępowe do usług chmurowych, zmienne środowiskowe z tokenami produkcyjnymi. Atakujący, który dostaje powłokę w środowisku Marimo, dostaje dostęp nie do jednego systemu — dostaje dostęp do kluczy od wielu systemów naraz.
Logi z pułapki Sysdig pokazują dokładnie ten wzorzec: atakujący po uzyskaniu dostępu od razu przeglądał strukturę katalogów i odczytywał plik .env. Nie szukał danych w samym notatniku. Szukał kluczy, które pozwolą mu wejść gdzieś dalej.
To dobrze pasuje do szerszego wzorca, który cyberflux opisywał przy okazji łańcucha dostaw: najcenniejszym łupem w środowisku deweloperskim często nie są same dane, lecz dostęp do innych systemów. Klucz AWS wyciągnięty z .env to wejście do infrastruktury chmurowej całej organizacji.
Co to mówi o oknie łatkowania
Tradycyjny model zakładał pewną sekwencję: ogłoszenie podatności → okres na łatkowanie → potem ewentualne ataki. Okno było liczone w dniach, a dla mniej głośnych narzędzi — tygodniach.
Marimo CVE-2026-39987 to kolejny przypadek pokazujący, że to okno skurczyło się do kilku godzin dla podatności, które są trywialne w eksploitacji. I nie chodzi wyłącznie o to, że atakujący są szybsi. Chodzi o to, że samo ostrzeżenie techniczne — wymagane przez standardy odpowiedzialnego ujawniania podatności — staje się wystarczającą instrukcją ataku, gdy podatność jest prosta.
To jest strukturalne napięcie, którego nie rozwiąże szybsze łatkowanie. Możesz mieć gotową łatkę w ciągu godziny od ogłoszenia — ale jak skutecznie zaktualizować tysiące instancji rozsianych po środowiskach programistycznych w tak krótkim czasie? Szczególnie gdy Marimo nie jest zarządzaną usługą chmurową z automatyczną aktualizacją, tylko oprogramowaniem uruchamianym lokalnie przez poszczególnych deweloperów i zespoły?
Rekomendacje
Marimo wydało poprawioną wersję 0.23.0 zawierającą łatkę. Dla tych, którzy nie mogą natychmiast zaktualizować — zablokowanie dostępu sieciowego do portu Marimo (domyślnie 2718) na poziomie zapory sieciowej lub wyłączenie punktu końcowego /terminal/ws eliminuje wektor ataku. Instancje Marimo nigdy nie powinny być wystawione bezpośrednio na internet bez dodatkowej warstwy uwierzytelniania.
Równie ważne: jeżeli instancja Marimo była dostępna publicznie w okolicach 8 kwietnia, należy założyć kompromitację i natychmiast rotować wszystkie klucze dostępowe przechowywane w środowisku — klucze chmurowe, tokeny API modeli językowych, dane dostępowe do baz danych.
Podsumowanie
CVE-2026-39987 w Marimo to historia nie tyle o konkretnej podatności, ile o tym, jak wygląda dziś okno między ogłoszeniem a atakiem dla prostych luk w narzędziach deweloperskich.
Brak uwierzytelnienia w terminalu to klasyczny błąd, znany od dekad. Nowe jest tempo: opis podatności stał się wystarczający do zbudowania działającego ataku. Narzędzie niszowe, bez publicznego kodu demonstracyjnego, zaatakowane w niecałe dziesięć godzin. Klucze wyciągnięte w mniej niż trzy minuty.
Jeżeli Antropic Mythos Preview pokazuje, co jest możliwe gdy model czyta kod i szuka w nim błędów — Marimo pokazuje, co jest możliwe gdy atakujący czyta ostrzeżenie i buduje na jego podstawie atak.
Okno na załatanie nie istnieje dla podatności, które można zrozumieć z opisu.
Źródła
Sysdig Threat Research Team — Marimo OSS Python Notebook RCE: From Disclosure to Exploitation in Under 10 Hours, pierwotna analiza z danymi z pułapek i chronologią ataku: https://webflow.sysdig.com/blog/marimo-oss-python-notebook-rce-from-disclosure-to-exploitation-in-under-10-hours
The Hacker News — omówienie CVE-2026-39987 i kontekst eksploitacji: https://thehackernews.com/2026/04/marimo-rce-flaw-cve-2026-39987.html
SecurityWeek — analiza przypadku i tempo eksploitacji: https://www.securityweek.com/critical-marimo-flaw-exploited-hours-after-public-disclosure/
BleepingComputer — szczegóły techniczne i rekomendacje: https://www.bleepingcomputer.com/news/security/critical-marimo-pre-auth-rce-flaw-now-under-active-exploitation/
