Wprowadzenie do problemu / definicja
W środowiskach notebookowych bezpieczeństwo nie zależy już wyłącznie od kodu uruchamianego w komórkach. Coraz większe znaczenie mają także metadane, konfiguracje projektu i mechanizmy integracyjne, które mogą wpływać na sposób przygotowania środowiska jeszcze przed świadomym uruchomieniem kodu przez użytkownika.
Właśnie taki problem dotyczył Marimo. Ujawniona podatność CVE-2026-75149 pozwalała na uruchomienie polecenia kontrolowanego przez atakującego jeszcze przed wykonaniem jakiejkolwiek komórki, jeśli ofiara otworzyła odpowiednio spreparowany notebook w trybie edycji.
W skrócie
Podatność dotyczyła wersji Marimo wcześniejszych niż 0.23.15 i została sklasyfikowana jako luka typu code injection. Problem wynikał z niewłaściwego zaufania do konfiguracji MCP osadzonej w pliku notebooka.
- Atak mógł zostać uruchomiony po samym otwarciu notebooka w trybie edycji.
- Nie było konieczne ręczne wykonanie komórek przez użytkownika.
- Skutkiem mogło być uruchomienie lokalnego podprocesu na systemie ofiary.
- Producent usunął błąd poprzez utwardzenie obsługi metadanych i ograniczenie zaufania do wybranych sekcji konfiguracyjnych.
Kontekst / historia
Marimo to nowoczesne środowisko notebookowe wykorzystywane m.in. w pracy z Pythonem, analizą danych oraz komponentami AI. Tego typu narzędzia przestają być prostymi kontenerami na kod. Coraz częściej zawierają również informacje o środowisku uruchomieniowym, integracjach i ustawieniach dodatkowych usług.
To właśnie ta ewolucja zwiększa powierzchnię ataku. Jeżeli aplikacja traktuje metadane notebooka jako zaufane, napastnik może umieścić w pliku konfigurację wpływającą na zachowanie programu po jego otwarciu. W praktyce oznacza to ryzyko, że plik projektu stanie się nośnikiem działań wykonawczych, a nie tylko treści analitycznej.
Przypadek Marimo wpisuje się w szerszy trend zagrożeń dotyczących narzędzi developerskich i AI, w których granica między danymi, konfiguracją i kodem wykonawczym staje się coraz mniej wyraźna. To szczególnie ważne w zespołach, które regularnie wymieniają się notebookami w ramach współpracy, testów lub badań.
Analiza techniczna
Istotą podatności było niewłaściwe traktowanie konfiguracji notebooka jako wiarygodnej. Atakujący mógł przygotować plik zawierający kontrolowaną przez siebie konfigurację MCP, a następnie dostarczyć go ofierze. Po otwarciu notebooka w trybie edycji aplikacja mogła uruchomić wskazane polecenie jako lokalny podproces.
Najgroźniejszym elementem tego scenariusza był moment wykonania. Złośliwa akcja następowała przed uruchomieniem komórek, czyli jeszcze zanim użytkownik wykonał jakikolwiek jawny krok kojarzony z uruchamianiem kodu. W efekcie klasyczna ostrożność polegająca na niewykonywaniu nieznanych komórek nie dawała pełnej ochrony.
Z perspektywy bezpieczeństwa był to przykład naruszenia granicy zaufania pomiędzy danymi dostarczonymi przez użytkownika, metadanymi notebooka, lokalnym środowiskiem wykonawczym oraz mechanizmami integracji z MCP. Producent ograniczył problem poprzez odfiltrowanie wybranych sekcji metadanych z kontekstu uruchomieniowego i utwardzenie logiki przetwarzania konfiguracji osadzonej w pliku.
Zmiany objęły m.in. obszary związane z AI, MCP, completion, secrets i server. Taki model obrony opiera się na zasadzie ograniczonego zaufania i jawnego dopuszczania tylko bezpiecznych ustawień zamiast akceptowania całej konfiguracji notebooka.
- Napastnik tworzy spreparowany notebook.
- W pliku osadza złośliwą konfigurację MCP.
- Notebook trafia do ofiary.
- Ofiara otwiera go w trybie edycji.
- Aplikacja uruchamia lokalny podproces zgodnie z podstawioną konfiguracją.
Technicznie problem można opisać jako połączenie code injection oraz niebezpiecznego ładowania konfiguracji z niezaufanego źródła. Krytyczna była tu faza przygotowania środowiska, a nie późniejsze wykonanie kodu przez użytkownika.
Konsekwencje / ryzyko
Ryzyko należy ocenić jako wysokie, szczególnie w organizacjach korzystających z notebooków do analiz, uczenia maszynowego, badań oraz integracji z narzędziami AI. Nawet pojedyncze uruchomienie podprocesu może otworzyć drogę do kolejnych etapów ataku.
- Lokalne wykonanie poleceń na stacji roboczej analityka lub dewelopera.
- Instalacja dodatkowego malware.
- Kradzież tokenów, kluczy API i sekretów środowiskowych.
- Dostęp do zasobów deweloperskich i chmurowych.
- Manipulacja wynikami analiz, skryptami lub artefaktami projektu.
Szczególnie niebezpieczny jest fakt, że ofiara nie musiała uruchamiać komórek notebooka. To zwiększa skuteczność socjotechniki, ponieważ wielu użytkowników zakłada, że samo otwarcie pliku jest bezpieczne. W praktyce takie założenie może prowadzić do kompromitacji stacji roboczych mających szerokie uprawnienia i dostęp do wrażliwych danych.
Nowoczesne środowiska notebookowe często mają bezpośredni dostęp do repozytoriów kodu, poświadczeń do usług AI, danych testowych lub produkcyjnych oraz lokalnych interpreterów i narzędzi systemowych. W takim kontekście nawet relatywnie prosty łańcuch ataku może skutkować poważnym incydentem.
Rekomendacje
Podstawowym krokiem powinno być sprawdzenie używanej wersji Marimo i aktualizacja wszystkich instancji do wersji zawierającej poprawkę lub nowszej. Sama aktualizacja nie powinna jednak kończyć działań ochronnych.
- Traktować notebooki z zewnętrznych źródeł jako niezaufane.
- Otwierać niezweryfikowane pliki wyłącznie w środowiskach izolowanych.
- Ograniczyć uprawnienia użytkowników pracujących z narzędziami notebookowymi.
- Oddzielić sekrety, tokeny i klucze API od codziennych środowisk roboczych.
- Monitorować tworzenie nowych procesów przez aplikacje notebookowe.
- Rejestrować nietypowe połączenia sieciowe inicjowane przez narzędzia developerskie.
- Wdrożyć EDR i kontrolę aplikacyjną na stacjach roboczych zespołów data i AI.
Z punktu widzenia hardeningu warto również zablokować automatyczne dziedziczenie zaufanej konfiguracji z plików projektowych, wdrożyć walidację i sanitizację metadanych notebooków oraz stosować model listy dozwolonych ustawień. Należy też przetestować integracje MCP i podobne mechanizmy pod kątem uruchamiania lokalnych komend podczas otwierania lub parsowania pliku.
Nie mniej ważny jest aspekt szkoleniowy. Użytkownicy powinni wiedzieć, że zagrożenie może wynikać nie tylko z kodu w komórkach, ale także z ukrytej konfiguracji osadzonej w notebooku. To istotna zmiana względem tradycyjnego modelu ryzyka w środowiskach analitycznych.
Podsumowanie
CVE-2026-75149 pokazuje, że notebooki stają się pełnoprawnym wektorem ataku, zwłaszcza gdy łączą kod, konfigurację i integracje AI w jednym pliku. W przypadku Marimo problem wynikał z możliwości dostarczenia złośliwej konfiguracji MCP, która prowadziła do uruchomienia lokalnego polecenia jeszcze przed wykonaniem komórek.
Najważniejsze wnioski są jednoznaczne: szybkie aktualizacje, izolacja niezaufanych notebooków i rygorystyczne traktowanie metadanych jako danych niegodnych zaufania powinny stać się standardem w środowiskach data science, AI i developmentu.