Kilka dni temu pisaliśmy o Marimo — notatniku programistycznym zaatakowanym w niecałe dziesięć godzin od momentu ujawnienia podatności. Tamta historia dotyczyła błyskawiczności: atakujący zbudował działający atak czytając sam opis, bez gotowego kodu demonstracyjnego, zanim większość administratorów zdążyła w ogóle przeczytać ostrzeżenie.
Flowise to historia dokładnie odwrotna i równie niepokojąca.
Podatność CVE-2025-59528 w Flowise została ujawniona we wrześniu 2025 roku. Łatka była dostępna tego samego dnia. Upłynęło sześć miesięcy. Siódmego kwietnia 2026 roku 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 i podatnych.
Nie dlatego że nie było łatki. Dlatego że nikt jej nie zastosował.
Czym jest Flowise i dlaczego ma dostęp do wszystkiego
Flowise to platforma open source do budowania przepływów pracy opartych na modelach językowych — popularne narzędzie wśród deweloperów tworzących własne aplikacje AI, chatboty, systemy automatyzacji i potoki agentowe. Interfejs przeciągaj-i-upuszczaj pozwala łączyć modele językowe z zewnętrznymi narzędziami, bazami danych i interfejsami programistycznymi bez głębokiej znajomości programowania. Ponad trzydzieści siedem tysięcy gwiazdek na GitHubie, używany przez duże korporacje i małe zespoły deweloperskie na całym świecie.
Żeby Flowise był użyteczny, musi mieć dostęp do wszystkiego z czym się łączy. Klucze do interfejsów API modeli językowych — OpenAI, Anthropic, Azure. Dane dostępowe do baz danych i magazynów wektorowych. Tokeny usług chmurowych. Zmienne środowiskowe z poświadczeniami do systemów wewnętrznych. Wszystko to siedzi w środowisku uruchomieniowym Flowise, gotowe do użycia przez skonfigurowane przepływy pracy.
Atakujący, który uzyska zdalne wykonanie kodu na instancji Flowise, dostaje dostęp nie do jednego systemu. Dostaje dostęp do kluczy od wszystkich systemów, z którymi ta instancja była skonfigurowana.
Gdzie siedzi podatność
CVE-2025-59528 dotyczy węzła CustomMCP — komponentu pozwalającego użytkownikom konfigurować połączenia z zewnętrznymi serwerami MCP. Użytkownik podaje konfigurację jako łańcuch tekstowy w parametrze mcpServerConfig. Kod Flowise przetwarza ten łańcuch, żeby zbudować konfigurację serwera.
Problem leży w tym jak go przetwarza. Zamiast walidować dane wejściowe i parsować je jako bezpieczne dane konfiguracyjne, kod wykonuje je jako JavaScript przy użyciu konstruktora Function() — czyli w praktyce eval() pod inną nazwą. Bez żadnej walidacji. Bez żadnego ograniczenia zakresu. Z pełnymi uprawnieniami procesu Node.js.
Atakujący wysyła jedno żądanie POST pod adres /api/v1/node-load-method/customMCP z odpowiednio spreparowaną konfiguracją i dostaje pełną powłokę na serwerze. Dostęp do modułu child_process oznacza wykonanie dowolnych poleceń systemowych. Dostęp do modułu fs oznacza odczyt dowolnych plików. Gdy Flowise działa jako root — a w wielu wdrożeniach tak jest — oznacza to pełne przejęcie maszyny.
W wersji z domyślnie wyłączoną autentykacją: żadnych poświadczeń, żadnego tokenu, jedno żądanie.
CVSS 10.0. Najwyższy możliwy wynik.
Trzy podatności z rzędu w tej samej platformie
CVE-2025-59528 nie jest pierwszą aktywnie eksploitowaną podatnością w Flowise. Jest trzecią.
Wcześniej były CVE-2025-26319 (CVSS 8.9) — dowolne przesyłanie plików — i CVE-2025-8943 (CVSS 9.8) — zdalne wykonanie poleceń systemowych. Obie były aktywnie wykorzystywane w atakach.
Wzorzec trzech kolejnych krytycznych podatności w tej samej platformie, każda aktywnie eksploitowana, jest sygnałem wykraczającym poza konkretne CVE. Caitlin Condon z VulnCheck ujmuje to wprost: to krytyczna podatność w popularnej platformie AI używanej przez wiele dużych korporacji. Ale ważniejsza obserwacja jest inna — platforma ta ma historię podatności, które wracają.
Dla organizacji korzystających z Flowise oznacza to, że pytanie nie brzmi tylko "czy załatałem tę konkretną lukę", ale "czy mam proces, który zapewni łatanie kolejnej, gdy się pojawi" — bo historia wskazuje, że pojawi się.
Sześć miesięcy z łatką
Łatka była dostępna we wrześniu 2025. Aktywna eksploitacja zaczęła się w kwietniu 2026. Między tymi datami jest sześć miesięcy, w których każdy administrator mógł zaktualizować platformę i całkowicie wyeliminować ryzyko.
Pytanie dlaczego tego nie zrobił jest ważniejsze niż pytanie o samą podatność.
Część odpowiedzi leży w tym jak traktowane są narzędzia deweloperskie w organizacjach. Flowise bardzo często jest instalowany jako narzędzie do prototypowania — "sprawdzimy jak to działa" — i zostaje. Nie przechodzi przez ten sam proces zarządzania podatnościami co systemy produkcyjne. Nie trafia do inwentarza aktywów, który jest regularnie skanowany. Nie ma wyznaczonego właściciela, który śledziłby nowe wersje i aktualizacje bezpieczeństwa. Jest po prostu uruchomiony na jakimś serwerze i działa.
Ale środowisko, w którym działa, nie jest środowiskiem deweloperskim. Zawiera klucze do produkcyjnych interfejsów API. Łączy się z produkcyjnymi bazami danych. Przetwarza dane, które mają wartość dla atakujących.
To jest "agentic security gap", który Salt Security opisuje w swoim raporcie z pierwszego półrocza 2026: organizacje wdrażają platformy agentowe w tempie, które wyprzedza zdolność do ich zabezpieczenia. Narzędzie deweloperskie z dostępem do infrastruktury produkcyjnej, traktowane jak narzędzie deweloperskie, nie jak element infrastruktury wymagający zarządzania.
Połączenie z MCP
Jest jeszcze jedna warstwa tej historii, która dobrze pasuje do wątku cyberflux.
Podatność siedzi dokładnie w węźle CustomMCP — komponencie integrującym Flowise z zewnętrznymi serwerami MCP. Mechanizm ataku to niesanitizowane wejście wykonywane jako kod, bo MCP z natury jest protokołem elastycznym, zaprojektowanym do obsługi różnorodnych konfiguracji. Ta elastyczność tworzy presję na deweloperów, żeby akceptowali szeroki zakres formatów danych wejściowych.
Gdy wcześniej pisaliśmy o klasycznych podatnościach w serwerach MCP — path traversal, wstrzykiwanie argumentów, brak autentykacji — pokazywaliśmy jak znane klasy błędów pojawiają się w nowej warstwie infrastruktury. CVE-2025-59528 pokazuje to samo z drugiej strony: platformy budujące na MCP dziedziczą ryzyko związane z przetwarzaniem danych konfiguracyjnych z zewnętrznych źródeł.
To nie jest przypadkowe. MCP jako protokół integracyjny jest z założenia miejscem gdzie zewnętrzne dane trafiają do środowiska wykonawczego agenta. Walidacja tych danych — zanim zostaną przetworzone, wykonane lub użyte do konfiguracji — jest fundamentem bezpieczeństwa całej warstwy agentowej. Flowise pokazuje co się dzieje gdy tego fundamentu nie ma.
Co zrobić
Aktualizacja do Flowise 3.1.1 lub nowszego usuwa podatność. To powinno być pierwszym krokiem dla każdego, kto ma wystawioną instancję Flowise.
Równie ważne: rotacja wszystkich kluczy i poświadczeń przechowywanych w środowisku Flowise. Jeśli instancja była dostępna publicznie w ostatnich miesiącach, nie wiadomo czy nie była już wcześniej skompromitowana przez jedną z dwóch poprzednich podatności. Klucze do interfejsów API modeli językowych, tokeny baz danych, zmienne środowiskowe z danymi dostępowymi — wszystkie należy traktować jako potencjalnie ujawnione.
Szerszy wniosek dla organizacji używających podobnych narzędzi: platformy do budowania agentów AI powinny być w tym samym rejestrze co pozostała infrastruktura wymagająca regularnego zarządzania podatnościami. Nie dlatego że są szczególnie niebezpieczne same w sobie — dlatego że mają dostęp do systemów, które są.
Podsumowanie
CVE-2025-59528 w Flowise i CVE-2026-39987 w Marimo to dwie strony tego samego problemu.
Marimo pokazało, że dla trywialnych podatności okno między ujawnieniem a atakiem może być krótsze niż dziesięć godzin — i żadna organizacja nie ma czasu na reakcję.
Flowise pokazuje, że dla wielu organizacji to okno nie ma żadnego znaczenia, bo łatka czekała sześć miesięcy i nikt jej nie zastosował.
W obu przypadkach wynik jest taki sam: atakujący ma dostęp do środowiska deweloperskiego z kluczami do całej infrastruktury.
Różnica jest tylko w tym, kogo winić. W pierwszym przypadku — tempo ataków. W drugim — zaległości w zarządzaniu podatnościami w narzędziach, które przestały być narzędziami deweloperskimi, ale nikt jeszcze tego nie zauważył.
Źródła
The Hacker News — CVE-2025-59528 i aktywna eksploitacja, dane VulnCheck: https://thehackernews.com/2026/04/flowise-ai-agent-builder-under-active.html
VulnCheck / Caitlin Condon — pierwotne wykrycie eksploitacji i dane o wystawionych instancjach: https://securityaffairs.com/190471/security/attackers-exploit-critical-flowise-flaw-cve-2025-59528-for-remote-code-execution.html
SonicWall — analiza techniczna łańcucha podatności i przepływu kodu: https://www.sonicwall.com/blog/flowiseai-custom-mcp-node-remote-code-execution-
Security Boulevard — kontekst i rekomendacje: https://securityboulevard.com/2026/04/max-severity-flowise-rce-vulnerability-now-exploited-in-attacks/
