Możliwość przejęcia dowolnego konta Flowise przez funkcję resetu hasła

Flowise to otwartoźródłowa platforma do tworzenia aplikacji opartych na sztucznej inteligencji, takich jak chatboty czy systemy agentowe. Umożliwia tworzenie scenariuszy przez wizualny interfejs (drag & drop), bez konieczności pisania dużej ilości kodu. Dzięki wsparciu dla LLM-ów (Large Language Models), RAG (Retrieval Augmented Generation) i integracji z różnymi źródłami danych pozwala łatwo korzystać z modeli AI do typowych zastosowań. 

TLDR:

• Flowise, popularna otwartoźródłowa platforma do tworzenia aplikacji AI, umożliwiała przejęcie konta dowolnego użytkownika – znając jedynie jego adres e-mail.
• Błąd w mechanizmie resetu hasła pozwalał przejąć konto dzięki tokenowi zwracanemu przez API.
• Dodatkowym problemem jest brak dwuetapowego uwierzytelniania i wymogu podania starego hasła przy wrażliwych operacjach.
• Luka została już załatana, ale ta sytuacja pokazuje, jak ważne jest stosowanie dobrych praktyk bezpieczeństwa przy tworzeniu aplikacji.

Jest to całkiem często stosowane narzędzie – repozytorium na GitHub zebrało prawie 50 tysięcy gwiazdek, a paczka npm zalicza tygodniowo średnio 2-3 tysiące instalacji.

Flowise można uruchomić na własnym serwerze, co daje elastyczność we wdrożeniu. Dodatkowo dostępna jest także wersja komercyjna – Flowise Cloud – gdzie za opłatą korzystamy z udostępnianej infrastruktury. Niestety oba te warianty objęła luka, pozwalająca na przejęcie konta dowolnego użytkownika.

Załatana już w najnowszej wersji podatność CVE-2025-58434 dotyczyła udostępniania tokenu do resetowania hasła bez uwierzytelnienia. Standardowo mechanizm ten realizuje się tak:

1. Użytkownik, który zapomniał hasła, używa opcji “Zapomniałem hasła” i jest proszony o adres e-mail lub nazwę użytkownika.
2. Bez względu na to, czy konto o podanej nazwie/adresie istnieje, system wyświetla generyczny komunikat, np. Jeśli podane konto istnieje, otrzymasz link do zmiany hasła – celem jest w tym momencie uniemożliwienie sprawdzenia, czy dany adres e-mail jest zarejestrowany w danej aplikacji.
3. Następnie – o ile konto istnieje – generowany jest (jednorazowy i ograniczony czasowo) token do resetowania hasła. Link z tym tokenem jest wysyłany e-mailem do użytkownika (na adres podany przy rejestracji konta).
4. Użytkownik po otwarciu linku (o ile token jest poprawny i ważny) ma możliwość ustawienia nowego hasła, bez konieczności podawania dotychczasowego.

W tym przypadku nie chodziło nawet o ujawnienie informacji o istnieniu danego konta. Atakujący, znając jedynie adres e-mail ofiary, mógł poznać token do resetowania hasła. A to oznacza, że mógł ustawić na dowolnym koncie własne hasło. Nie trzeba nawet wspominać, że uzyskiwał wtedy pełny dostęp do takiego konta.

Gdy użytkownik zażąda resetu hasła, aplikacja wysyła żądanie do API z podanym adresem e-mail. Serwer oprócz sprawdzenia adresu i wysłania maila, zwraca w odpowiedzi pełne dane o koncie użytkownika.

Można więc poznać identyfikator (UUID) konta, przypisaną do niego nazwę, ale także hasło (w formie hasza) i – co najgorsze – token do jego zresetowania. Wykonując zapytanie do tego samego endpointu API i zamieszczając w nim otrzymany token, można bez problemu zmienić hasło wybranemu użytkownikowi.

Dobrze zabezpieczone aplikacje powinny wymagać ponownego wpisania hasła przy bardziej wrażliwych czynnościach na koncie użytkownika. Takimi czynnościami mogą być np. zmiana hasła, wylogowanie innych sesji, czy konfiguracja uwierzytelniania dwuetapowego.

Atakujący może w tym przypadku ustawić własne hasło, więc tego typu zabezpieczenia go nie dotyczą. Niestety, Flowise w ogóle takich nie stosuje. W ustawieniach konta można znaleźć opcję zmiany hasła:

Wcale nie trzeba znać dotychczasowej wartości, by ustawić nowe. Nie trzeba również znać hasła, by ustawić dwuetapowe uwierzytelnianie (2FA). A to dlatego, że takiej opcji po prostu nie ma.

Głównym problemem jest tu nie tylko przywołana podatność, ale też niezbyt rzetelne podejście Flowise do bezpiecznych praktyk w aplikacji. Dobrze wdrożona dwuetapowa weryfikacja – której narzędzie w ogóle nie miało – nie jest nadpisywana przez reset hasła (co do zasady, ewentualne odzyskiwanie 2FA nie powinno być możliwe razem z hasłem). Gdyby aplikacja posiadała taką funkcję, możliwości wykorzystania znalezionej podatności mogłyby być ograniczone.

Dla programistów wniosek powinien być prosty: poprawnie implementować mechanizmy dwuetapowego uwierzytelniania oraz zmiany i resetowania haseł. Więcej na ten temat można poczytać w materiałach PortSwigger.

W przypadku tej konkretnie luki pomogłoby też stosowanie unikalnych loginów/adresów e-mail – np. za pomocą aliasów. Atakujący musiałby dodatkowo odgadnąć taką wartość, która – dopóki nie pojawi się np. w wycieku – nie będzie mu znana. Taka strategia standardowo powinna być bezużyteczna, jednak działa z powodu niestosowania dobrych praktyk przez twórców aplikacji. Jest to rozwiązanie defense in depth – wdrożenie dodatkowych (pozornie niepotrzebnych) zabezpieczeń, zakładając z góry że poprzednie (standardowe) nie zadziałają.

Źródła:

• cyberpress.org
• cybersecuritynews.com
• github.com
• github.com

~Tymoteusz Jóźwiak