Przez lata model bezpieczeństwa oparty na zarządzaniu podatnościami wyglądał tak: producent ujawnia błąd, publikuje łatkę, organizacje mają okno — kilka dni, tydzień, może dwa tygodnie — zanim atakujący zbudują działający atak i zanim zaczną się masowe eksploitacje. W tym oknie powinna nastąpić aktualizacja.
To okno zawsze było umowne. Nigdy nie było gwarantowane. Ale przez wiele lat działało wystarczająco dobrze, żeby traktować je jako podstawę planowania.
W ciągu jednego tygodnia kwietnia 2026 roku dwa osobne incydenty pokazały, że to okno przestało istnieć — z dwóch zupełnie różnych powodów.
Pierwsza perspektywa: okno zamknięte, zanim je otworzyłeś
8 kwietnia 2026 roku twórcy Marimo opublikowali szczegółowe ostrzeżenie o krytycznej podatności w swoim notatniku programistycznym. Opisali dokładnie który punkt końcowy jest podatny, dlaczego pomija autentykację i co przez to jest możliwe. Nie opublikowali gotowego kodu demonstracyjnego.
9 godzin i 41 minut później zespół badawczy Sysdig zanotował pierwsze aktywne próby ataku na swoje środowiska-pułapki. Atakujący nie potrzebował gotowego kodu — sam opis wystarczył. Połączył się z podatnym punktem końcowym, uruchomił kilka poleceń rozpoznawczych i w ciągu trzech minut wyciągnął klucze dostępowe do chmury.
Dla administratora, który rano przeczytał ostrzeżenie i zaplanował aktualizację na popołudnie — było już za późno.
Podatność w Marimo była trywialna w eksploitacji. Terminal WebSocket bez autentykacji oznacza: połącz się, pisz polecenia, odbieraj wyniki. Nie trzeba żadnego ładunku, żadnej precyzji, żadnej znajomości architektury. Ostrzeżenie techniczne opisało to wystarczająco dokładnie, żeby każdy kto je przeczytał mógł odtworzyć atak w kilka minut.
Dla tego rodzaju podatności okno nie istnieje od momentu publikacji ostrzeżenia. Jest tylko pytanie czy atakujący przeczyta je szybciej niż administrator.
Druga perspektywa: okno było, ale nikt go nie użył
We wrześniu 2025 roku Flowise ujawnił CVE-2025-59528 — podatność CVSS 10.0 w węźle CustomMCP, który wykonuje dane wejściowe użytkownika jako JavaScript bez żadnej walidacji. Jedno żądanie, pełny dostęp do systemu. Łatka była dostępna tego samego dnia, w wersji 3.0.6.
7 kwietnia 2026 roku — sześć miesięcy później — VulnCheck zanotował pierwsze aktywne próby eksploitacji. W tym momencie między dwunastoma a piętnastoma tysiącami instancji Flowise było wystawionych na internet. Podatnych, bo niezaktualizowanych.
Nie dlatego że nie było czasu. Sześć miesięcy to czas wystarczający. Nie dlatego że łatka była trudna do zastosowania. Aktualizacja pakietu npm i restart serwisu. Dlatego że nikt nie traktował Flowise jako elementu infrastruktury wymagającego aktywnego zarządzania bezpieczeństwem.
Flowise jest bardzo często instalowany jako narzędzie do prototypowania. Zostaje uruchomiony, działa, integruje się z produkcyjnymi kluczami API i bazami danych — ale w głowach administratorów pozostaje "narzędziem deweloperskim", nie "systemem produkcyjnym". Nie trafia do rejestru aktywów, który jest regularnie skanowany. Nie ma właściciela śledzącego nowe wersje. Nie przechodzi przez ten sam proces zarządzania podatnościami co reszta infrastruktury.
Okno było przez sześć miesięcy. Nikt nie skorzystał.
Dwa różne powody, ten sam wynik
Zestawione razem Marimo i Flowise opisują pełną przestrzeń awarii modelu opartego na zarządzaniu podatnościami.
Po jednej stronie jest Marimo: podatność na tyle prosta, że opis techniczny wystarczy do zbudowania ataku. Okno nie istnieje bo tempo eksploitacji przekroczyło tempo reakcji ludzkiej. Nawet najsprawniejszy administrator nie zaktualizuje tysiąca instancji w dziesięć godzin.
Po drugiej stronie jest Flowise: podatność znana od pół roku, łatka dostępna, czas wystarczający — ale narzędzie poza zasięgiem procesów bezpieczeństwa. Okno istniało, ale organizacja nie wiedziała że ma okno do zamknięcia.
W pierwszym przypadku problem jest techniczny: szybkość eksploitacji przekroczyła możliwości ludzkich procesów reagowania. W drugim przypadku problem jest organizacyjny: platforma agentowa wypadła poza pererymetr bezpieczeństwa, który organizacja faktycznie chroni.
Oba przypadki dotyczą narzędzi do budowania i uruchamiania agentów AI. Oba mają dostęp do środowisk zawierających klucze do interfejsów API, tokeny usług chmurowych, dane dostępowe do baz danych. W obu przypadkach skutek eksploitacji to nie tyle kompromitacja samego narzędzia, ile dostęp do wszystkiego z czym to narzędzie jest połączone.
Co to oznacza w praktyce
Model "ujawnienie → okno → łatka → bezpieczeństwo" zakładał dwie rzeczy, które przestają być prawdziwe jednocześnie.
Pierwsza: że masz czas na reakcję po ujawnieniu. Dla podatności trywialnych w eksploitacji — takich gdzie sam opis wystarczy do zbudowania ataku — tego czasu może nie być. Atakujący monitorują źródła informacji o podatnościach szeroko i potrafią zbudować działający atak w godzinach.
Druga: że wiesz o wszystkich systemach, które musisz zaktualizować. Wraz z ekspansją narzędzi agentowych i platform AI w środowiskach deweloperskich rośnie liczba komponentów infrastruktury, które mają dostęp do wrażliwych zasobów, ale nie są objęte standardowymi procesami zarządzania bezpieczeństwem.
Odpowiedzią na pierwsze wyzwanie jest skrócenie cykli aktualizacji i automatyzacja tam gdzie to możliwe. Odpowiedzią na drugie jest rozszerzenie inwentarza: platformy do budowania agentów AI, notatniki programistyczne, narzędzia do tworzenia przepływów pracy — wszystko co ma dostęp do kluczy i poświadczeń produkcyjnych powinno być traktowane jak infrastruktura produkcyjna, niezależnie od tego jak zostało pierwotnie zainstalowane.
Obie odpowiedzi są trudne do wdrożenia w organizacjach, w których tempo adopcji AI wyprzedza tempo adaptacji procesów bezpieczeństwa. Ale właśnie to opisuje kwiecień 2026.
Źródła
Sysdig Threat Research Team — analiza eksploitacji Marimo CVE-2026-39987 z danymi z pułapek: https://webflow.sysdig.com/blog/marimo-oss-python-notebook-rce-from-disclosure-to-exploitation-in-under-10-hours
The Hacker News — Flowise CVE-2025-59528 i aktywna eksploitacja: https://thehackernews.com/2026/04/flowise-ai-agent-builder-under-active.html
SecurityWeek — analiza tempa eksploitacji Marimo: https://www.securityweek.com/critical-marimo-flaw-exploited-hours-after-public-disclosure/
VulnCheck / Security Affairs — dane o wystawionych instancjach Flowise i historia podatności: https://securityaffairs.com/190471/security/attackers-exploit-critical-flowise-flaw-cve-2025-59528-for-remote-code-execution.html
