Krytyczna luka RCE w Flowise: złośliwy import chatflow może przejąć serwer

Wprowadzenie do problemu / definicja

Flowise to popularna platforma open source wykorzystywana do budowy agentów AI, workflow opartych na dużych modelach językowych oraz integracji z narzędziami zewnętrznymi. Najnowsze analizy bezpieczeństwa wskazują jednak, że sposób obsługi mechanizmu Custom MCP może prowadzić do krytycznej podatności typu zdalne wykonanie kodu (RCE), umożliwiającej przejęcie serwera.

Problem dotyczy scenariusza, w którym uwierzytelniony użytkownik importuje spreparowany plik chatflow. Taki pozornie zwykły plik konfiguracyjny może zawierać parametry prowadzące do uruchomienia złośliwych poleceń w środowisku hostującym Flowise.

W skrócie

• Podatność została opisana jako CVE-2026-40933.
• Atak ma charakter one-click RCE i wymaga nakłonienia zalogowanego użytkownika do importu złośliwego chatflow.
• Źródłem problemu jest obsługa Custom MCP, zwłaszcza konfiguracji wykorzystujących transport stdio.
• Publicznie dostępny kod PoC zwiększa ryzyko szybkiego wykorzystania luki w realnych środowiskach.
• Najbardziej zagrożone są self-hostowane instancje Flowise z dostępem do sekretów, usług wewnętrznych i funkcji importu workflow.

Kontekst / historia

Wraz ze wzrostem popularności agentów AI rośnie także znaczenie bezpieczeństwa warstw integracyjnych, które łączą modele językowe z lokalnymi procesami, usługami API i zasobami infrastrukturalnymi. Model Context Protocol zyskuje na znaczeniu jako standard komunikacji między aplikacjami AI a narzędziami zewnętrznymi, ale jednocześnie poszerza powierzchnię ataku.

Flowise należy do grupy platform, które upraszczają tworzenie złożonych przepływów pracy oraz gotowych integracji. To właśnie ta wygoda staje się jednak ryzykowna, gdy aplikacja pozwala importować gotowe workflow z zewnętrznych źródeł. W takim modelu plik konfiguracyjny przestaje być jedynie neutralnym opisem logiki i może stać się nośnikiem niebezpiecznych instrukcji.

Opisana luka wpisuje się w szerszy trend problemów bezpieczeństwa wokół narzędzi agentowych i implementacji MCP. Szczególnie niebezpieczne okazują się sytuacje, w których warstwa integracyjna może uruchamiać lokalne procesy, a walidacja parametrów wejściowych jest niepełna lub opiera się na łatwych do obejścia mechanizmach filtrowania.

Analiza techniczna

Kluczowym elementem podatności jest sposób, w jaki Flowise obsługuje Custom MCP w konfiguracjach korzystających z transportu stdio. Mechanizm ten pozwala aplikacji uruchamiać lokalny proces i komunikować się z nim przez standardowe wejście oraz wyjście. Funkcjonalnie daje to dużą elastyczność, ponieważ umożliwia szybkie podłączanie własnych serwerów MCP i narzędzi uruchamianych przez lokalne binaria, interpretery czy menedżery pakietów.

Z perspektywy bezpieczeństwa tworzy to jednak bezpośrednie połączenie między konfiguracją dostarczoną przez użytkownika a wykonywaniem poleceń systemowych. Jeśli aplikacja nie stosuje ścisłej listy dozwolonych procesów, odpowiednio nie separuje argumentów, nie wymusza bezpiecznej serializacji oraz pozwala na import gotowych workflow, wówczas atakujący może przygotować chatflow prowadzący do wykonania nieautoryzowanego kodu.

Istotne jest również to, że scenariusz ataku nie wymaga od ofiary zaawansowanej interakcji. W praktyce wystarcza import złośliwego pliku przez zalogowanego operatora. To obniża próg wejścia dla napastnika, ponieważ spreparowany plik może zostać przedstawiony jako legalny szablon automatyzacji, integracji AI lub gotowy komponent usprawniający pracę zespołu.

Badacze zwrócili także uwagę, że częściowe zabezpieczenia można obchodzić. Jeżeli mechanizmy ochronne opierają się głównie na blacklistingu komend lub prostym filtrowaniu wzorców wejściowych, architektura nadal pozostaje narażona na nadużycia. W praktyce oznacza to, że sam model uruchamiania lokalnych procesów z poziomu warstwy integracyjnej stanowi istotne ryzyko projektowe.

Konsekwencje / ryzyko

Skuteczna eksploatacja luki może prowadzić do pełnego przejęcia środowiska, w którym działa Flowise. W zależności od architektury wdrożenia skutki mogą objąć zarówno sam kontener aplikacji, jak i szerszą infrastrukturę sieciową.

• przejęcie hosta lub kontenera uruchamiającego Flowise,
• dostęp do kluczy API, tokenów i innych sekretów zapisanych w konfiguracji,
• odczyt, modyfikację lub usunięcie lokalnych plików,
• ruch boczny do innych systemów dostępnych z poziomu podatnej instancji,
• manipulację agentami AI i wynikami ich działania,
• utrwalenie obecności napastnika w środowisku.

Najwyższe ryzyko dotyczy organizacji, które wystawiają panel Flowise do internetu, przechowują w nim poświadczenia do usług chmurowych i źródeł danych oraz pozwalają użytkownikom importować workflow pochodzące spoza organizacji. Szczególnie narażone są środowiska współdzielone, gdzie wielu operatorów korzysta z jednego panelu i ufa gotowym szablonom.

Rekomendacje

Podatność należy traktować jako problem wysokiego priorytetu operacyjnego. Organizacje korzystające z Flowise powinny jak najszybciej ograniczyć ekspozycję i wdrożyć działania naprawcze.

• Niezwłocznie zaktualizować Flowise do wersji zawierającej poprawki bezpieczeństwa.
• Zweryfikować, czy w środowisku nie działają starsze, testowe lub zapomniane instancje aplikacji.
• Tymczasowo wyłączyć lub silnie ograniczyć funkcję importu chatflow oraz użycie Custom MCP, jeśli nie są niezbędne.
• Ograniczyć dostęp do panelu administracyjnego wyłącznie przez VPN, segmentację sieci lub dodatkową kontrolę tożsamości.
• Uruchamiać Flowise w odizolowanym środowisku o minimalnych uprawnieniach i bez zbędnego dostępu do zasobów hosta.
• Wdrożyć allowlistę dozwolonych procesów, binariów i parametrów uruchamianych przez integracje MCP.
• Monitorować logi pod kątem importu nowych workflow, nietypowych procesów potomnych, wywołań powłoki i zmian konfiguracyjnych.
• Przeprowadzić rotację sekretów, tokenów i kluczy API, jeśli istnieje podejrzenie kompromitacji.
• Traktować wszystkie importowane workflow jak potencjalnie niebezpieczny kod, a nie zwykłe pliki konfiguracyjne.

Dodatkowo warto przyjąć zasadę, że każdy komponent MCP zdolny do uruchamiania lokalnych procesów powinien być klasyfikowany jako krytyczna powierzchnia ataku. Oznacza to potrzebę twardej izolacji, jawnego modelu zaufania i rygorystycznej kontroli konfiguracji.

Podsumowanie

Luka CVE-2026-40933 w Flowise pokazuje, że środowiska AI stają się pełnoprawnym celem ataków infrastrukturalnych. Problem nie ogranicza się wyłącznie do pojedynczego błędu implementacyjnego, lecz wynika z niebezpiecznego połączenia funkcji integracyjnych, uruchamiania lokalnych procesów i zaufania do importowanych workflow.

Publicznie dostępny PoC dodatkowo zwiększa prawdopodobieństwo szybkiej weaponizacji. Dla zespołów bezpieczeństwa to wyraźny sygnał, że platformy agentowe AI wymagają takiego samego poziomu hardeningu, segmentacji i monitoringu jak klasyczne systemy o krytycznym znaczeniu dla organizacji.

Źródła

1. Infosecurity Magazine — https://www.infosecurity-magazine.com/news/flowise-mcp-rce-poc/
2. Obsidian Security: 1-Click RCE in Flowise (CVE-2026-40933): When Is stdio MCP Actually a Vulnerability? — https://www.obsidiansecurity.com/blog/when-is-stdio-mcp-actually-a-vulnerability
3. CSO Online: Flowise’s MCP implementation can run ghost commands — https://www.csoonline.com/article/4179309/flowises-mcp-implementation-can-run-ghost-commands.html
4. FlowiseAI Documentation: Tools & MCP — https://docs.flowiseai.com/tutorials/tools-and-mcp
5. Cloud Security Alliance: Flowise CVSS 10.0 RCE: AI Agent Builders Under Attack — https://labs.cloudsecurityalliance.org/research/csa-research-note-flowise-mcp-rce-exploitation-20260409-csa/