Podatności Flowise

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, 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 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 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.

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.

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 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.3 ma nieuwierzytelniony endpoint odświeżania tokenów OAuth2, który wykonuje żądania HTTP po stronie serwera do kontrolowanego przez atakującego adresu URL bez ochrony SSRF, ujawniając odpowiedź i dane uwierzytelniające.

Flowise przed wersją 3.1.0 zawiera podatność na przechodzenie po ścieżkach w implementacjach przechowywania wektorów Faiss i SimpleStore. Uwierzytelnieni użytkownicy mogą podać niesanitowany parametr basePath, co pozwala na zapis danych wektorowych w dowolnej lokalizacji systemu plików.

Podatność w Flowise przed wersją 3.1.2 polega na ustawieniu nagłówka Access-Control-Allow-Origin na stałą wartość wildcard (*) w punkcie końcowym generowania mowy (TTS). Powoduje to obejście skonfigurowanej polityki CORS serwera i umożliwia dowolnej stronie internetowej wykonywanie żądań cross-origin z wykorzystaniem zapisanych poświadczeń.

Podatność w Flowise przed wersją 3.1.3 umożliwia ominięcie listy zablokowanych zmiennych środowiskowych dla węzłów Custom MCP. Na systemie Windows, gdzie nazwy zmiennych środowiskowych nie rozróżniają wielkości liter, użycie 'node_options' zamiast 'NODE_OPTIONS' pozwala na wstrzyknięcie opcji --require i wykonanie dowolnego kodu.

Flowise przed wersją 3.0.10 (dotknięte wersje 3.0.7 i wcześniejsze) nie unieważnia istniejących sesji i tokenów sesji po zmianie hasła przez użytkownika. Atakujący, który posiada aktywną sesję, na przykład poprzez skradziony token sesji lub pozostawione zalogowane urządzenie, pozostaje uwierzytelniony jako uprawniony użytkownik nawet po zmianie jego poświadczeń.

Flowise przed wersją 3.0.10 zawiera lukę polegającą na braku weryfikacji bieżącego hasła podczas zmiany hasła przez uwierzytelnionego użytkownika. Atakujący, który przejmie sesję, może bez podania starego hasła zmienić hasło ofiary, co prowadzi do pełnego przejęcia konta.

Flowise przed wersją 3.0.6 zawiera podatność na odczyt dowolnego pliku w parametrze chatId endpointów /api/v1/get-upload-file oraz /api/v1/openai-assistants-file/download. Wartość chatId nie jest walidowana i przekazywana do funkcji streamStorageFile(), gdzie ścieżka wyszukiwania pliku skonstruowana bez orgId jest oceniana po sprawdzeniu ograniczenia katalogu przechowywania, co umożliwia przejście poza zamierzony katalog. Nieuwierzytelnieni atakujący mogą odczytać wrażliwe pliki, takie jak /root/.flowise/database.sqlite, ujawniając całą zawartość bazy danych w domyślnej konfiguracji.

Podatność w Flowise przed wersją 3.1.0 (wersje 3.0.13 i wcześniejsze) polega na braku uwierzytelnienia w punkcie końcowym /api/v1/loginmethod. Niezalogowani atakujący mogą, podając parametr organizationId, pobrać pełną konfigurację SSO organizacji, w tym sekrety klientów OAuth w postaci jawnego tekstu dla integracji z Google, Microsoft/Azure, GitHub i Auth0.

Flowise w wersjach przed 3.1.0 zawiera podatność typu server-side request forgery (SSRF) w węźle Execute Flow, która pozwala atakującym na obejście walidacji bezpieczeństwa poprzez podanie adresów intranetowych w polu podstawowego URL. Atakujący mogą inicjować żądania HTTP do adresów wewnętrznych sieci oraz uzyskiwać dostęp do metadanych chmurowych.

Flowise w wersjach przed 3.0.10 (dotknięte wersje 3.0.7 i wcześniejsze) zawiera podatność na niezweryfikowaną zmianę adresu e-mail. Użytkownik z autoryzacją może zmienić adres e-mail konta bez potwierdzenia zmiany na oryginalny adres e-mail lub ponownego wprowadzenia aktualnego hasła.

Flowise w wersjach przed 3.1.2 zawiera podatność na ujawnienie informacji w punkcie końcowym /api/v1/chatflows/apikey/:apikey. Brak parametru zapytania keyonly powoduje, że punkt końcowy zwraca nie tylko chatflow związane z dostarczonym kluczem API, ale także wszystkie chatflow w każdym workspace, które nie mają przypisanego klucza API.

Flowise w wersjach przed 3.1.2 zawiera podatność na masowe przypisanie w punkcie końcowym PUT /api/v1/user, co pozwala uwierzytelnionym użytkownikom na bezpośrednią modyfikację pola poświadczeń bez walidacji. Atakujący mogą obejść weryfikację zmiany hasła oraz unieważnienie sesji, dostarczając spreparowany skrót hasła, co umożliwia trwały dostęp do konta po tymczasowym naruszeniu sesji.

Flowise w wersjach przed 3.0.13 zawiera podatność na ujawnienie informacji w punkcie końcowym POST /api/v1/account/forgot-password, który zwraca pełne obiekty użytkowników, w tym dane osobowe, nieautoryzowanym atakującym. Atakujący może enumerować ważne adresy e-mail i zbierać wrażliwe dane użytkowników, wysyłając żądania z znanymi adresami e-mail.

Flowise w wersjach przed 3.0.8 zawiera podatność typu cross-site scripting (XSS) spowodowaną niewystarczającym filtrowaniem danych wejściowych w wiadomościach czatu oraz funkcjach agentów niestandardowych. Atakujący może wstrzyknąć złośliwy kod JavaScript, co prowadzi do kradzieży ciasteczek i danych sesji.

Podatność typu mass-assignment w Flowise przed wersją 3.1.2 umożliwia przejęcie ewaluatora między obszarami roboczymi (cross-workspace).

Podatność typu mass-assignment w Flowise przed wersją 3.1.2 umożliwia przejęcie ewaluacji między obszarami roboczymi (cross-workspace).

Podatność typu mass-assignment w Flowise przed wersją 3.1.2 umożliwia przejęcie wierszy DatasetRow między obszarami roboczymi (cross-workspace).

Flowise przed wersją 3.1.2 umożliwia przejęcie zbioru danych z innego obszaru roboczego poprzez masowe przypisanie podczas tworzenia i aktualizacji zbioru danych. Luka została załatana w wersji 3.1.2.

Flowise przed wersją 3.1.2 umożliwia przejęcie szablonu z innego obszaru roboczego poprzez masowe przypisanie podczas tworzenia i aktualizacji szablonu niestandardowego. Luka została załatana w wersji 3.1.2.

Flowise przed wersją 3.1.2 umożliwia przejęcie asystenta z innego obszaru roboczego poprzez masowe przypisanie podczas tworzenia i aktualizacji asystenta. Luka została załatana w wersji 3.1.2.

Flowise przed wersją 3.1.2 nie posiada uwierzytelniania ani kontroli dostępu dla endpointów CRUD OpenAI Assistants Vector Store. Brak autoryzacji przy użyciu klucza API.

Flowise przed wersją 3.1.2 nie usuwa pola encryptedData z odpowiedzi API podczas pobierania poświadczeń z użyciem filtra credentialName. Bez filtra pole jest pomijane, ale z filtrem już nie, co prowadzi do wycieku zaszyfrowanych danych.

Flowise przed wersją 3.1.2 zawiera podatność na masowe przypisanie w endpointcie aktualizacji chatflow. Umożliwia ona uwierzytelnionemu użytkownikowi modyfikację właściwości kontrolowanych przez serwer, takich jak deployed, isPublic, workspaceId, oraz przeniesienie zasobu do innego obszaru roboczego.

Podatność typu mass assignment w Flowise pozwala uwierzytelnionym użytkownikom na modyfikację właściwości kontrolowanych przez serwer, takich jak workspaceId, podczas aktualizacji narzędzia. Brak walidacji po stronie serwera umożliwia przypisanie narzędzi do dowolnych przestrzeni roboczych.