Podatności Flowise

Flowise przed wersją 3.1.3 zawiera niekompletną podatność na redakcję poświadczeń w punkcie końcowym GET /api/v1/credentials/:id, który zwraca odszyfrowane sekrety w postaci zwykłego tekstu. Uwierzytelnieni użytkownicy z uprawnieniem credentials:view mogą pobierać wrażliwe dane, w tym adresy URL połączeń z bazami danych z osadzonymi hasłami, JSON kont usług chmurowych z kluczami prywatnymi oraz klucze API, wywołując ten punkt końcowy.

Flowise przed wersją 3.1.3 zawiera podatność na niebezpieczne bezpośrednie odwołanie do obiektu w punkcie końcowym GET /api/v1/organization/customer-default-source, która umożliwia uwierzytelnionym atakującym dostęp do danych płatności i profili innych klientów poprzez manipulację parametrem customerId. Atakujący mogą enumerować przewidywalne identyfikatory klientów, aby pobrać wrażliwe informacje, w tym adresy e-mail, salda kont, typy walut i konfiguracje rozliczeń bez kontroli autoryzacji.

Flowise przed wersją 3.1.3 zawiera podatność ucieczki z piaskownicy w pythonCodeValidator.ts, która nie blokuje natywnych metod Pandas DataFrame, takich jak to_csv, to_json, pipe i query. Uwierzytelnieni atakujący mogą to wykorzystać do eksfiltracji przesłanych danych CSV lub zapisu dowolnych plików w systemie plików serwera.

Flowise to interfejs typu 'przeciągnij i upuść' do budowania spersonalizowanych przepływów dużych modeli językowych. Przed wersją 3.1.3, moduł bezpieczeństwa HTTP Flowise (httpSecurity.ts) nie normalizował adresów IPv4-mapped IPv6, takich jak ::ffff:127.0.0.1 i ::ffff:169.254.169.254, przed sprawdzeniem ich na liście zablokowanych. Ponieważ ipaddr.js raportuje te adresy jako ipv6, podczas gdy wpisy CIDR IPv4 na liście zablokowanych są ipv4, funkcja isDeniedIP() pomijała sprawdzenia CIDR IPv4. Atakujący, który kontroluje rozwiązywanie DNS dla nazwy hosta używanej przez węzeł HTTP, API Chain, Document Loader, narzędzie MCP lub inne ścieżki używające secureAxiosRequest(), secureFetch() lub checkDenyList(), mógł zwrócić rekord AAAA dla celu z adresem IPv4-mapped i spowodować, że żądania dotrą do localhost, usług wewnętrznych lub punktów końcowych metadanych chmury. Ten problem został naprawiony w wersji 3.1.3.

Brak kontroli uprawnień w trasie /api/v1/files w Flowise przed wersją 3.1.3, co pozwala niskouprzywilejowanym kluczom API na listowanie i usuwanie plików w całej organizacji.

Flowise przed wersją 3.1.3 zawiera podatność ucieczki z piaskownicy vm2, która pozwala uwierzytelnionym użytkownikom na wykonanie dowolnego kodu poprzez obejście walidacji locale moment.js i załadowanie złośliwych plików JavaScript z magazynu dokumentów.

Flowise przed wersją 3.1.3 zawiera podatność zdalnego wykonania kodu w węźle Custom MCP, gdy CUSTOM_MCP_PROTOCOL jest ustawiony na stdio, pozwalając uwierzytelnionym użytkownikom na wykonanie dowolnych poleceń poprzez manipulację zmiennymi środowiskowymi i argumentami poleceń.

Flowise przed wersją 3.1.3 zawiera podatność obejścia walidatora kodu Python opartego na regex w węzłach CSV i Airtable Agent, która pozwala nieuwierzytelnionym atakującym na wstrzyknięcie złośliwego kodu przez prompt injection.

Flowise przed wersją 3.1.3 zawiera podatność wstrzykiwania kodu w parametrze customReadCSV w węźle CSV Agent, która pozwala uwierzytelnionym atakującym na wykonanie dowolnego kodu Python. Walidator używa statycznej listy blokad regex, którą można obejść przez zaciemnianie.

Flowise przed wersją 3.1.3 zawiera podatność wstrzykiwania kodu w węźle Airtable Agent, która pozwala nieuwierzytelnionym atakującym na wykonanie dowolnego kodu Python poprzez obejście listy blokad pythonCodeValidator za pomocą zaciemniania.

Flowise (pakiety flowise i flowise-components) w wersjach do 3.1.2 zawiera podatność ucieczki z piaskownicy vm2/@flowiseai/nodevm. Uwierzytelniony użytkownik z dostępem do /api/v1/node-custom-function może uciec z piaskownicy, podając kontrolowane parametry executablePath i args do puppeteer.launch(), co prowadzi do wykonania dowolnych poleceń systemowych i ujawnienia plików hosta.

Podatność w Flowise (do wersji 3.1.4) w integracji OpenAI Assistants pozwala uwierzytelnionym atakującym na dostęp do danych uwierzytelniających innych obszarów roboczych poprzez podanie dowolnego UUID poświadczeń bez weryfikacji własności obszaru roboczego.

Flowise przed wersją 3.1.3 zawiera podatność w punkcie końcowym POST /api/v1/oauth2-credential/refresh/:credentialId, który jest na liście dozwolonych i nie wymaga uwierzytelnienia. Atakujący ze znajomością ID poświadczenia może odświeżyć token OAuth i uzyskać dostęp do połączonej usługi ofiary oraz wyczerpać limit odświeżania tokenów.

Flowise przed wersją 3.1.3 zawiera podatność na wstrzyknięcie promptu w węźle CSV Agent, co pozwala na wykonanie złośliwego skryptu Pythona w środowisku Pyodide bez sandboxa. Atakujący może wykorzystać to do wykonania dowolnego kodu w kontekście konta usługi.

Flowise przed wersją 3.1.3 zawiera podatność w walidatorze kodu Python, która pozwala na ominięcie zabezpieczeń za pomocą homoglifów Unicode, umożliwiając wykonanie dowolnego kodu Python w Pyodide oraz pełne wykonanie poleceń systemowych na hoście Flowise.

Flowise przed wersją 3.1.3 zawiera podatność w CSVAgent, która pozwala atakującemu na wstrzyknięcie kodu do szablonu Pythona wykonywanego przez Pyodide, co umożliwia wykonanie dowolnych poleceń systemowych na hoście Flowise. Nieuwierzytelnione żądanie do API może wywołać zdalne wykonanie kodu.

Flowise przed wersją 3.1.3 zawiera podatność w węźle SQLite Record Manager, która pozwala uwierzytelnionemu atakującemu na nadpisanie ścieżki bazy danych SQLite i umieszczenie złośliwej składni w pliku konfiguracyjnym, co może prowadzić do wykonania kodu podczas uruchamiania Chromium.

Flowise przed wersją 3.1.3 zawiera podatność w węźle CSVAgent, która pozwala uwierzytelnionemu użytkownikowi na wykonanie dowolnego kodu przez deserializację złośliwego ładunku pickle, omijając listę zablokowanych konstrukcji Pythona.

Flowise przed wersją 3.1.3 zawiera podatność w komponencie CSVAgent, gdzie dane CSV kontrolowane przez atakującego są wstawiane bezpośrednio do kodu Python wykonywanego przez Pyodide. Uwierzytelniony atakujący może wstrzyknąć kod Python, który przez mostek js Pyodide ładuje child_process i wykonuje dowolne polecenia systemowe jako root w kontenerze Flowise.

Flowise przed wersją 3.1.3 zawiera podatność w funkcji executeJavaScriptCode(), która akceptuje nodeVMOptions od wywołującego i scala je z domyślnymi ustawieniami bezpieczeństwa NodeVM. Uwierzytelniony atakujący może uruchomić niestandardową funkcję, która importuje utils.js, wywołuje executeJavaScriptCode() z opcjami umożliwiającymi dostęp do wszystkich wbudowanych modułów, a następnie używa child_process do wykonania dowolnych poleceń systemowych jako root na serwerze Flowise.

Flowise przed wersją 3.1.3 zawiera podatność na wstrzykiwanie kodu w komponentach AgentAsTool, ChatflowTool i ExecuteFlow, które uruchamiają kod w sandboxie vm2. Wartość baseURL kontrolowana przez użytkownika jest wstawiana bezpośrednio do kodu JavaScript, a jedyną walidacją jest isValidURL, która nie zapobiega przełamaniu ciągu znaków. Uwierzytelniony użytkownik może wstrzyknąć własny kod JavaScript, który może uciec z sandboxa i wykonać dowolny kod na serwerze Flowise.

Flowise przed wersją 3.1.3 pozwala uwierzytelnionym użytkownikom na ustawienie dowolnych opcji TypeORM DataSource przez pole additionalConfig w kilku węzłach menedżera rekordów i pamięci agenta. Opcje takie jak entities, subscribers i migrations mogą ładować lokalne pliki JavaScript, co umożliwia wykonanie dowolnego kodu na serwerze poprzez przesłanie złośliwego pliku JavaScript i odniesienie się do niego w additionalConfig.entities. Problem został naprawiony w wersji 3.1.3.

Flowise przed wersją 3.1.0 (wersje 3.0.13 i wcześniejsze) używa słabych, zakodowanych na stałe domyślnych sekretów JWT ('auth_token', 'refresh_token') oraz domyślnych wartości odbiorcy i wystawcy ('AUDIENCE', 'ISSUER') w oprogramowaniu pośredniczącym uwierzytelniania passport. Gdy zmienne środowiskowe nie są ustawione, aplikacja po cichu używa tych publicznie znanych domyślnych wartości, co pozwala atakującemu na fałszowanie ważnych tokenów JWT i podszywanie się pod dowolnego użytkownika, w tym administratorów.

Flowise przed wersją 3.1.0 (dotknięte wersje 3.0.13 i wcześniejsze) używa słabego, zakodowanego na stałe domyślnego sekretu ('flowise') dla middleware express-session, gdy zmienna środowiskowa EXPRESS_SESSION_SECRET nie jest ustawiona. Ponieważ ten domyślny sekret jest publicznie widoczny w kodzie źródłowym, atakujący może sfałszować ważne podpisane ciasteczka sesji, aby podszyć się pod dowolnego użytkownika i ominąć uwierzytelnianie.

Flowise zawiera podatność polegającą na przechodzeniu poza katalog (path traversal) w punkcie końcowym /api/v1/document-store/loader/process, która umożliwia nieuwierzytelnionym atakującym zapisywanie dowolnych plików w systemie plików. Atakujący mogą wykorzystać niesanitowane parametry fileName z sekwencjami ../ do nadpisania krytycznych plików, takich jak package.json, i uzyskać zdalne wykonanie kodu po ponownym uruchomieniu aplikacji.

Flowise przed wersją 3.0.6 (dotknięte wersje 2.2.7-patch.1 i wcześniejsze) zawiera podatność na zdalne wykonanie kodu bez sandboksa w funkcji Custom MCP. Atakujący może wysłać spreparowany ładunek JSON z nagłówkiem 'x-request-from: internal' do endpointu /api/v1/node-load-method/customMCP, aby wykonać dowolne polecenia systemowe, co prowadzi do całkowitego przejęcia kontenera lub serwera.

Flowise przed wersją 3.0.6 (dotknięte wersje 2.2.8 i wcześniejsze) zawiera podatność na dowolny dostęp do plików z powodu braku walidacji, czy parametry chatflowId i chatId są UUID lub liczbami w operacjach na plikach. Poprzez podanie wartości typu path traversal (np. '../../../../../tmp') jako identyfikatora chatflow, nieuwierzytelniony atakujący może użyć endpointu /api/v1/chatflows (poprzez addBase64FilesToStorage) do zapisu dowolnych plików oraz endpointów /api/v1/get-upload-file i /api/v1/openai-assistants-file/download (poprzez streamStorageFile) do odczytu dowolnych plików. Dowolny zapis plików może prowadzić do zdalnego wykonania kodu.

Flowise w wersji do 2.2.4 zawiera nieuwierzytelnioną podatność na dowolne przesyłanie plików w punkcie końcowym /api/v1/attachments, gdy storageType jest ustawiony na local. Atakujący mogą wykorzystać przejście ścieżki w parametrach chatId i chatflowId, aby przesłać złośliwe pliki do dowolnych katalogów, co może prowadzić do zdalnego wykonania kodu i przejęcia serwera.

Flowise zawiera podatność polegającą na pominięciu uwierzytelniania w niechronionym punkcie końcowym /api/v1/account/register, co umożliwia nieuwierzytelnionym atakującym tworzenie kont użytkowników. Zdalni atakujący mogą wykorzystać ten punkt końcowy do rejestracji dowolnych kont i uwierzytelnienia się w systemie, uzyskując pełny dostęp do API bez poświadczeń.

Flowise w wersjach przed 2.1.4 pozwala na wstrzykiwanie konfiguracji do Chainflow podczas wykonywania za pomocą opcji overrideConfig. Funkcja ta jest domyślnie włączona i nie posiada listy dozwolonych zmiennych, co umożliwia atakującym zdalne wykonanie kodu oraz inne poważne ataki.

Podatność w Flowise przed wersją 3.1.2 umożliwia uwierzytelnionemu atakującemu zdalne wykonanie kodu poprzez przesłanie dowolnego JavaScript do węzła Custom JS Function. Brak autoryzacji na ścieżce POST /api/v1/node-custom-function.

Flowise przed wersją 3.1.2 zawiera podatność na masowe przypisanie w punkcie końcowym aktualizacji asystenta. Uwierzytelniony użytkownik może modyfikować właściwości kontrolowane przez serwer, takie jak workspaceId, createdDate i updatedDate. Brak walidacji po stronie serwera i kontroli autoryzacji umożliwia atakującemu manipulację polem workspaceId i przenoszenie asystentów do dowolnych przestrzeni roboczych.

W Flowise przed wersją 3.1.2, endpoint checkBasicAuth weryfikuje dane uwierzytelniające w postaci jawnego tekstu bez ograniczania szybkości żądań i z bezpośrednim porównaniem. Umożliwia to atakującemu przeprowadzenie ataku brute-force na hasła.

W Flowise przed wersją 3.1.2 istnieje podatność masowego przypisania w endpointcie aktualizacji zmiennych. Uwierzytelniony atakujący może modyfikować właściwości kontrolowane przez serwer, takie jak workspaceId, co może naruszyć izolację dzierżawców w środowiskach wieloobszarowych.

Flowise to interfejs typu drag & drop do budowania dostosowanych przepływów dużych modeli językowych. W wersjach przed 3.1.0, kilka implementacji narzędzi bezpośrednio importuje i wywołuje surowe klienty HTTP, co stwarza lukę bezpieczeństwa.

Flowise w wersjach od 3.0.1 do 3.0.8 oraz wszystkich późniejszych z włączoną opcją 'ALLOW_BUILTIN_DEP' zawiera podatność na zdalne wykonanie kodu (RCE) z ominięciem sandboksa Node VM. Uwierzytelniony atakujący może wykorzystać zintegrowane moduły Puppeteer i Playwright do uruchomienia dowolnego pliku wykonywalnego na hoście.

Flowise przed wersją 3.1.4 nie waliduje widoczności chatflow w nieuwierzytelnionym punkcie końcowym zamiany tekstu na mowę, co pozwala atakującym na nadużywanie poświadczeń TTS prywatnych chatflow. Nieuwierzytelnieni atakujący mogą generować nieograniczoną liczbę plików audio tekstu na mowę, używając zapisanych kluczy API OpenAI lub ElevenLabs, podając prawidłowy UUID chatflow, co generuje koszty na koncie właściciela chatflow.

Flowise w wersjach od 2.2.4 do 3.1.4 ma brak autoryzacji w punkcie końcowym POST /api/v1/openai-assistants-file/download, który jest na globalnej liście dozwolonych bez uwierzytelnienia. Niezalogowany atakujący może uzyskać dostęp do prywatnych plików z dowolnego chatflow, w tym z innych organizacji.

Flowise do wersji 3.1.4 zawiera podatność na podrabianie żądań po stronie serwera (SSRF) w zabezpieczeniu SSRF zaimplementowanym w httpSecurity.ts, gdzie DEFAULT_DENY_LIST pomija endpoint metadanych Oracle Cloud Infrastructure (192.0.0.192) oraz Alibaba Cloud (100.100.100.200). Umożliwia to uwierzytelnionym atakującym zmuszenie serwera do wysyłania dowolnych żądań GET do usług metadanych instancji chmurowych, a w przypadku publicznych chatflow z węzłami pobierania URL możliwy jest dostęp bez uwierzytelnienia.

Flowise do wersji 3.1.4 zawiera podatność obejścia uwierzytelniania, która pozwala nieuwierzytelnionym atakującym na dostęp do punktu końcowego odświeżania poświadczeń OAuth2 poprzez wykorzystanie dopasowania białej listy opartej na prefiksie w middleware uwierzytelniającym. Atakujący mogą wysłać żądanie POST do trasy odświeżania z końcowym identyfikatorem poświadczeń, aby ominąć wszystkie kontrole uwierzytelniania i autoryzacji, wywołując nieautoryzowaną rotację tokenów OAuth i potencjalnie zakłócając zależne integracje OAuth.

Flowise do wersji 3.1.4 zawiera podatność braku autoryzacji, która pozwala uwierzytelnionym członkom przestrzeni roboczej na wykonywanie nieautoryzowanych operacji na magazynie dokumentów poprzez dostęp do niechronionych punktów końcowych mutacji. Atakujący posiadający tylko uprawnienia do podglądu mogą wysyłać bezpośrednie żądania HTTP do tras upsert i odświeżania, aby wywołać ingerencję dokumentów, odświeżyć zawartość bazy wektorowej, zużyć kredyty API osadzania i modyfikować bazy wiedzy używane przez chatflow.

Flowise przed wersją 3.1.3 nie weryfikuje, czy identyfikator subskrypcji Stripe należy do organizacji uwierzytelnionego użytkownika. Uwierzytelniony atakujący może wykonywać nieautoryzowane operacje na subskrypcjach Stripe innych dzierżawców, w tym zmieniać plany lub liczbę miejsc.

Flowise przed wersją 3.1.3 zawiera podatność w endpointcie PUT /api/v1/executions/:id, który nie posiada middleware checkAnyPermission() chroniącego inne endpointy wykonawcze. Każdy uwierzytelniony użytkownik, niezależnie od przypisanych uprawnień, może modyfikować stan, dane i metadane dowolnego wykonania w swoim workspace, co umożliwia eskalację uprawnień i manipulację wynikami przepływów pracy.

Flowise przed wersją 3.1.3 ma trzy punkty końcowe OAuth2, które wyszukują poświadczenia tylko po identyfikatorze, bez filtra workspaceId. Umożliwia to uwierzytelnionym użytkownikom inicjowanie przepływów OAuth2 dla poświadczeń innych obszarów roboczych, a nieuwierzytelnionym atakującym nadpisywanie tokenów lub odświeżanie tokenów dowolnych poświadczeń.

Flowise przed wersją 3.1.3 nie ogranicza dostępu do historii operacji upsert do konkretnego użytkownika, dzierżawcy lub obszaru roboczego. Odpowiedź z punktu końcowego GET /api/v1/upsert-history może przekraczać 100 MB i zawierać wrażliwe dane konfiguracyjne, w tym ustawienia Vector Store, takie jak adres URL serwera Qdrant i nazwa kolekcji. Brakuje autoryzacji, izolacji oraz limitów, co ujawnia parametry integracji i szczegóły infrastruktury.

Flowise przed wersją 3.1.3 w punktach końcowych openai-assistants-vector-store akceptuje kontrolowany przez klienta parametr poświadczeń i ładuje poświadczenia według identyfikatora bez sprawdzania, czy należą one do obszaru roboczego wywołującego. Uprawnienia trasy assistants:* sprawdzają tylko dostęp do funkcji, a kontroler przekazuje req.query.credential bezpośrednio do usługi, która odszyfrowuje poświadczenia i wywołuje API OpenAI bez sprawdzenia workspaceId. Atakujący znający identyfikator poświadczeń innego obszaru roboczego może użyć klucza OpenAI ofiary, czytać, modyfikować lub usuwać wektory i pliki ofiary, powodować obciążenia na koncie OpenAI ofiary i naruszać granice wielodostępności.

Flowise przed wersją 3.1.3 wstrzykuje $vars do piaskownicy wykonywania kodu bez wymagania uprawnienia variables:view, omijając chroniony API zmiennych. Użytkownik lub klucz API bez uprawnień variables:view może wywołać /api/v1/node-custom-function i otrzymać wszystkie zmienne obszaru roboczego, w tym sekrety.

Flowise to interfejs typu 'przeciągnij i upuść' do budowania spersonalizowanych przepływów dużych modeli językowych. Przed wersją 3.1.3, obejście dla CVE-2025-8943 blokowało flagi -y i --yes w npx, ale plik packages/components/nodes/tools/MCP/core.ts odrzucał tylko PATH, LD_LIBRARY_PATH, DYLD_LIBRARY_PATH i NODE_OPTIONS według dokładnej nazwy zmiennej środowiskowej. Ponieważ npm czyta konfigurację ze zmiennych npm_config_*, ustawienie npm_config_yes=true odtwarzało zachowanie --yes bez użycia zablokowanej flagi, powodując automatyczną instalację i wykonanie nazwanego pakietu przez npx podczas uruchamiania niestandardowego serwera MCP. Ten problem został naprawiony w wersji 3.1.3.

Flowise to interfejs typu 'przeciągnij i upuść' do budowania spersonalizowanych przepływów dużych modeli językowych. Przed wersją 3.1.3, endpoint `DELETE /api/v1/chatflows/:id` autoryzował żądania za pomocą checkAnyPermission('chatflows:delete,agentflows:delete'), więc posiadanie któregokolwiek z tych uprawnień było wystarczające do osiągnięcia ścieżki usuwania. Logika usuwania rozwiązywała docelowy rekord tylko po id i workspaceId i nie walidowała typu zasobu, co pozwalało wywołującemu z uprawnieniem tylko agentflows:delete na usunięcie CHATFLOW, a wywołującemu z uprawnieniem tylko chatflows:delete na usunięcie AGENTFLOW w tym samym workspace. Ten problem został naprawiony w wersji 3.1.3.

Flowise to interfejs typu 'przeciągnij i upuść' do budowania spersonalizowanych przepływów dużych modeli językowych. Przed wersją 3.1.3, nieuwierzytelniony endpoint POST /api/v1/prediction/:id akceptował obiekt overrideConfig i bezwarunkowo rozprzestrzeniał go do wewnętrznych obiektów flowConfig i flowData w plikach packages/server/src/utils/buildChatflow.ts i packages/server/src/utils/index.ts bez sprawdzania apiOverrideStatus. To pozwalało nieuwierzytelnionym atakującym na wstrzykiwanie dowolnych właściwości do kontekstu wykonania przepływu dowolnego publicznego chatflow, nadpisywanie wartości takich jak chatId, sessionId i chatHistory oraz kontrolowanie wartości rozwiązywanych przez zmienne szablonu $flow.* używane przez węzły przepływu. Ten problem został naprawiony w wersji 3.1.3.