Przejdź do treści
INDEKS ANALIZ BREACHROAD / NOTA TECHNICZNA

Typebot 3.18.0: przejęcie konta i odczyt plików serwera w platformie chatbotów

CVE-2026-62862 i CVE-2026-62865 łączą słabe kody logowania z eksfiltracją plików przez Nodemailer. Analiza poprawek Typebot 3.18.0 i plan reakcji.

MATERIAŁ PUBLICZNY
AUTOR
/ CEO Breachroad · OSCP · PNPT
PUBLIKACJA
26 sierpnia 2026
CZAS CZYTANIA
18 min czytania
TEMAT
Bezpieczeństwo AI
Typebot 3.18.0: przejęcie konta i odczyt plików serwera w platformie chatbotów

Aktualizacja Typebot 3.18.0 zamyka dwie poważne klasy błędów w samodzielnie hostowanej platformie do budowy chatbotów. CVE-2026-62862 pozwalało anonimowemu napastnikowi zgadywać sześciocyfrowy kod magic link i przejąć konto użytkownika. CVE-2026-62865 umożliwiało autorowi bota wykorzystanie załączników w bloku Send Email do odczytu pliku dostępnego dla procesu serwera i wysłania go na kontrolowaną skrzynkę. Rekordy CVE trafiły do publicznych katalogów 25 sierpnia wieczorem UTC, czyli w polskiej strefie informacyjnie zamykają dobę 26 sierpnia.

To nie jest luka „w modelu językowym”. Typebot jest warstwą orkiestracji rozmowy, integracji i danych wokół chatbotów, a podatności znajdują się w uwierzytelnianiu oraz serwerowej obsłudze wiadomości e-mail. Właśnie dlatego są ważne dla bezpieczeństwa AI: kompromitacja panelu pozwala czytać wyniki rozmów, zmieniać przepływy i używać zapisanych poświadczeń integracji bez atakowania samego modelu.

Dwa błędy, jeden niebezpieczny łańcuch skutków

Pierwsza luka ma ocenę CVSS 4.0 9,1 (Critical). Dotyczy samodzielnie hostowanych instalacji do wersji 3.17.1 włącznie, które używają domyślnego logowania bez hasła przez e-mail. Dostawca uwierzytelniania zastępował bezpieczny token NextAuth sześciocyfrową wartością wygenerowaną przez Math.random(). Przestrzeń wynosiła 900 000 kodów, a czas życia dziesięć minut.

Sama krótka wartość nie musi oznaczać przejęcia konta, jeśli serwer ogranicza próby, unieważnia kod po błędzie, wiąże weryfikację z rozpoczętą sesją i stosuje odporny na obejście limiter. Tutaj callback weryfikacyjny nie miał blokady ani limitu zgadywania. Niepoprawna próba nie zużywała właściwego tokenu. Ograniczenie obejmowało ścieżkę wysyłania kodu, ale opierało klucz na kontrolowanym nagłówku X-Forwarded-For. Według advisory kody współistniały, więc wiele aktywnych wartości zwiększało prawdopodobieństwo trafienia.

Druga luka otrzymała CVSS 4.0 8,7 (High). Blok Send Email pobierał wartość załącznika ze zmiennej Typebot i przekazywał ją do Nodemailer jako path. Gdy wartość nie zaczynała się od własnego bazowego URL aplikacji, helper nie odrzucał jej ani nie wymagał schematu HTTP/HTTPS — zwracał ścieżkę bez zmian. Transport Nodemailer nie ustawiał disableFileAccess ani disableUrlAccess, a domyślne wartości tych zabezpieczeń zezwalają na dostęp.

Autor bota mógł więc wskazać lokalny plik jako załącznik oraz kontrolowany adres jako odbiorcę. Proces viewer/chat-api odczytywał zawartość z własnymi uprawnieniami, a następnie wysyłał ją pocztą. Nie oznacza to automatycznie dostępu do każdego pliku hosta: granicą pozostają uprawnienia systemowe i izolacja kontenera. W typowym środowisku proces widzi jednak konfigurację aplikacji, zamontowane sekrety albo zmienne środowiskowe dostępne przez system plików procesu.

Token logowania jest poświadczeniem. Jego bezpieczeństwo zależy od entropii i całego protokołu, nie od tego, czy wartość zostanie później zahaszowana w bazie. Hash chroni zapis przed prostym odczytem, ale serwer nadal może porównywać każdy poprawnie sformatowany kod przesłany przez sieć. Gdy przestrzeń ma 900 000 elementów i nie ma wiarygodnego limitu, atakujący może wykonywać testy online.

Math.random() nie jest kryptograficznym generatorem liczb pseudolosowych. Ważniejsze w tej konkretnej luce jest jednak połączenie małej przestrzeni z nieograniczonym callbackiem. Nawet idealnie równomierny sześciocyfrowy kod byłby za słaby, jeżeli system akceptuje nieograniczoną liczbę prób w czasie jego ważności. Wielowarstwowa ochrona powinna obejmować CSPRNG, wystarczającą długość, pojedynczy aktywny token, atomowe zużycie, limit na konto i kontekst oraz sygnały ryzyka.

Limiter bazujący na adresie IP musi też rozumieć architekturę proxy. Aplikacja nie powinna bezwarunkowo ufać pierwszej wartości nagłówka przesłanej przez klienta. Zaufane proxy może nadpisać nagłówek i przekazać zweryfikowany adres, ale wymaga to jawnej listy pośredników i poprawnej konfiguracji frameworka. W przeciwnym razie napastnik sam wybiera klucz, który miał ograniczać jego żądania.

Jak załącznik stał się kanałem odczytu serwera

Biblioteki pocztowe obsługują ścieżki celowo: serwer może dołączyć raport wygenerowany na dysku bez ładowania całego pliku do pamięci. To bezpieczna funkcja tylko wtedy, gdy ścieżkę wybiera zaufany kod. W Typebot wartość pochodziła ze zmiennej używanej podczas wykonania przepływu, a fallback traktował dowolny ciąg jak lokalizację dostępną dla Nodemailer.

Kontrola prefiksu bazowego URL nie tworzy allowlisty protokołów ani katalogów. Pytanie „czy wartość nie jest naszym adresem?” nie odpowiada na pytanie „czym jest ta wartość?”. Bezpieczny parser powinien rozpoznawać dokładnie dopuszczone typy: identyfikator wcześniej przesłanego pliku, podpisany adres z kontrolowanego magazynu lub HTTPS do zatwierdzonej domeny. Lokalna ścieżka nie powinna powstawać z danych respondenta.

Druga bariera należy do transportu. Nawet jeśli wcześniejszy helper popełni błąd, disableFileAccess: true i — jeżeli funkcja nie wymaga pobierania URL — disableUrlAccess: true redukują skutek. Następne bariery to konto systemowe bez dostępu do sekretów innych usług, read-only filesystem, minimalne mounty oraz osobny worker do wysyłki poczty.

Kto jest rzeczywiście zagrożony

CVE-2026-62862 dotyczy self-hosted Typebot przed 3.18.0 z aktywnym dostawcą e-mail/magic-link. Instalacje używające wyłącznie OAuth lub SSO, bez provider’a e-mail, nie są objęte opisanym mechanizmem. Nie należy jednak oceniać konfiguracji wyłącznie na podstawie przycisku widocznego na ekranie: trzeba sprawdzić skuteczne zmienne środowiskowe i dostępne callbacki.

CVE-2026-62865 dotyczy self-hosted buildera i viewera przed 3.18.0, gdy można uruchomić blok Send Email z załącznikiem sterowanym zmienną. Advisory wskazuje, że otwarta rejestracja była ustawieniem domyślnym, a skonfigurowane SMTP potrzebne do magic linków zapewniało gotowy kanał wysyłki. Jeżeli rejestracja jest wyłączona, atak wymaga istniejącego konta autora bota, ale nadal nie musi wymagać administratora.

W tym samym wydaniu naprawiono również CVE-2026-62861: członek jednego workspace mógł podać nazwę domeny należącej do innego tenant’a i usunąć ją ze wspólnego projektu Vercel, ponieważ autoryzacja workspaceId nie była powiązana z obiektem domeny przed operacją zewnętrzną. To osobny błąd BOLA/IDOR, ale potwierdza potrzebę przeglądu wszystkich granic tenantów w integracjach zarządzających współdzieloną infrastrukturą.

Plan aktualizacji i krótkoterminowe ograniczenia

Najlepszym działaniem jest aktualizacja wszystkich komponentów Typebot do 3.18.0 lub nowszej wspieranej wersji. Builder, viewer i chat-api powinny pochodzić z tej samej, zweryfikowanej wersji obrazu. Po wdrożeniu należy wymusić nowe uruchomienie workloadów i potwierdzić wersję wewnątrz działającego kontenera, a nie tylko tag w deklaracji Compose lub Helm.

Jeśli zmiana nie może wejść natychmiast, wyłączenie providera e-mail usuwa ścieżkę CVE-2026-62862, o ile organizacja ma działające SSO/OAuth. Ograniczenie rejestracji, dezaktywacja bloku Send Email albo odseparowanie jego workerów może zmniejszyć ekspozycję drugiej luki. Są to bariery tymczasowe: reverse proxy nie naprawi semantyki callbacku, jeżeli nie wprowadza limitów powiązanych z tożsamością i nie uniemożliwia spoofingu adresu.

Po aktualizacji unieważnij aktywne sesje, kody weryfikacyjne i tokeny API w zakresie wspieranym przez platformę. Jeżeli plik z sekretami lub środowisko procesu mogły zostać odczytane, zmień ENCRYPTION_SECRET, dane bazy, SMTP i klucze integracji zgodnie z procedurą rotacji. Zmiana klucza szyfrującego wymaga planu migracji zapisanych poświadczeń; nie usuwaj starego materiału zanim nie wiadomo, jak platforma odszyfruje istniejące rekordy.

Detekcja: czego szukać po fakcie

Dla przejęcia konta przeglądaj serię callbacków magic-link z wieloma różnymi kodami, dużą liczbę odpowiedzi przekierowujących, nagłe zmiany X-Forwarded-For i wiele żądań wysyłki dla jednego adresu. Połącz logi proxy z logami aplikacji — dopiero zaufana warstwa wejściowa pozwala ustalić źródłowy adres. Podejrzane jest utworzenie sesji po długiej serii błędów bez typowego wejścia z klienta pocztowego.

Dla odczytu plików szukaj wykonań Send Email, w których wartość załącznika nie jest zatwierdzonym URL ani identyfikatorem uploadu. Przydatne są logi SMTP, historia edycji botów i telemetria dostępu do plików procesu. Alarm powinien objąć odczyty katalogów konfiguracyjnych i pseudoplików procesu przez worker wysyłkowy, a także wysyłkę załączników do nowej domeny odbiorcy.

Brak takiego logu nie dowodzi bezpieczeństwa. Jeżeli instalacja była publiczna, otwarta na rejestrację i długo działała na podatnej wersji, wykonaj analizę ekspozycji sekretów. Po rotacji obserwuj stare poświadczenia: próby ich użycia są wartościowym IOC i mogą wskazać, że luka została faktycznie wykorzystana.

Lekcja dla platform AI i chatbotów

System chatbotowy przetwarza więcej niż prompt. Ma panel autora, uwierzytelnianie, webhooki, pocztę, storage, domeny, poświadczenia modeli i dane rozmów. Każda integracja rozszerza graf zaufania. Bezpieczeństwo AI musi więc obejmować klasyczne kontrole aplikacyjne: silne sesje, autoryzację obiektową, izolację tenantów, bezpieczną obsługę plików i minimalne prawa procesów.

Zespół powinien modelować przepływ od publicznej zmiennej bota do każdego sinka po stronie serwera. Jeżeli wartość dociera do path, URL, szablonu, zapytania lub nazwy zasobu w chmurze, musi istnieć pozytywna walidacja i wtórna blokada w bibliotece wykonawczej. Testy bezpieczeństwa powinny obejmować najniższą rolę, ustawienia domyślne i łańcuch kilku pozornie niezależnych funkcji.

Fakty źródłowe i wnioski Breachroad

Zakres wersji, mechanizm sześciocyfrowych kodów, zachowanie callbacku, przepływ załącznika do Nodemailer, oceny CVSS i poprawka 3.18.0 pochodzą z advisories projektu Typebot oraz rekordów CVE. Źródła nie podają potwierdzonej aktywnej eksploatacji. Scenariusze rotacji, korelacji logów i architektury wielowarstwowych zabezpieczeń są wnioskami Breachroad.

Szkolenia z bezpieczeństwa AI i bezpiecznego tworzenia aplikacji uczą zespoły rozpoznawać takie granice danych i tożsamości, a testy aplikacji webowych i API mogą zweryfikować konfigurację chatbotów, izolację tenantów oraz integracje serwerowe.

Źródła

UDOSTĘPNIJ / KOPIUJ