Podatności n8n

W resolverze setWebhookResolver w aplikacji (prawdopodobnie n8n) brakuje walidacji adresu URL dostarczonego przez użytkownika. Uwierzytelniony użytkownik może sprawić, że serwer wyśle powtarzane żądania do wewnętrznych punktów końcowych, w tym do adresów link-local (metadata). Odpowiedź nie jest zwracana przez API, więc atak jest ślepy.

Podatność w n8n przed wersjami 1.123.67, 2.31.5 i 2.32.1 umożliwia obejście autoryzacji poświadczeń w węźle HTTP Request. Uwierzytelniony członek z prawem edycji do współdzielonego przepływu pracy może odwołać się do poświadczeń innego użytkownika, podając typ poświadczeń przez wyrażenie. Ponieważ kontrola uprawnień przed wykonaniem porównuje nierozwiązane wyrażenie zamiast faktycznego typu poświadczeń, kontrola własności jest pomijana i poświadczenia są ładowane w czasie wykonania, co pozwala na ich użycie lub eksfiltrację.

Podatność w n8n przed wersjami 2.31.5 i 2.32.1 umożliwia przejęcie konta przez funkcję Token Exchange Embed Login. Gdy prawidłowo podpisany token przychodzący został dopasowany do lokalnego konta na podstawie adresu e-mail, usługa nie weryfikowała, czy adres e-mail jest potwierdzony, ani czy dozwolony poziom roli zaufanego klucza obejmuje to konto. W rezultacie każdy, kto uzyska token akceptowany przez skonfigurowany zaufany klucz, może uwierzytelnić się jako dowolny istniejący użytkownik i uzyskać pełną kontrolę nad kontem.

n8n przed wersjami 1.123.67, 2.31.5 i 2.32.1 zawiera podatność na zanieczyszczenie prototypu w silniku wyrażeń VM. Uwierzytelniony użytkownik, który może tworzyć lub edytować wyrażenie przepływu pracy, może wykorzystać dostęp do elementów tablicy silnika, aby uzyskać referencję do wbudowanego obiektu hosta i zanieczyścić jego prototyp w głównym procesie n8n (ucieczka z sandboxa), co prowadzi do odmowy usługi. Dotyczy to zarówno instancji self-hosted, jak i chmurowych uruchamiających silnik wyrażeń VM.

Podatność w n8n przed wersjami 1.123.67, 2.31.5 i 2.32.1 umożliwia zdalne wykonanie kodu w węźle Git. Uwierzytelnieni użytkownicy z prawami do tworzenia i wykonywania przepływów pracy mogą przygotować spreparowane lokalne repozytorium, które powoduje uruchomienie hooków git przy domyślnych ustawieniach bezpieczeństwa, wykonując dowolne polecenia jako użytkownik procesu n8n. Dotyczy to zarówno instancji self-hosted, jak i chmurowych.

JavaScript task runner w n8n współdzielił pojedynczą pamięć podręczną modułów między wykonywaniami kodu wszystkich użytkowników. W dotkniętych wersjach (przed 1.123.67, 2.31.5 i 2.32.1) użytkownik mogący uruchomić węzeł Code mógł zatruć moduł w pamięci podręcznej, a tym samym zmienić wykonywania węzłów Code innych użytkowników na tym samym runnerze, wpływając na ich poufność, integralność lub dostępność. Jest to przerwanie izolacji między użytkownikami w ramach jednej instancji n8n i nie stanowi ucieczki z sandboxa ani zdalnego wykonywania kodu. Dotyczy to tylko instancji wieloużytkownikowych uruchamiających JS task runner z wbudowanymi lub zewnętrznymi modułami.

Podatność w n8n przed wersjami 1.123.67, 2.31.5 i 2.32.1 umożliwia dowolny zapis plików w węźle Edit Image, który przekazuje parametr formatu wyjściowego do biblioteki obrazów bez walidacji. Uwierzytelniony użytkownik mogący uruchamiać przepływy pracy może dostarczyć spreparowaną wartość formatu, aby zapisać dowolne pliki poza katalogiem roboczym węzła na instancji n8n.

n8n to platforma automatyzacji procesów roboczych typu open source. Przed wersjami 1.123.32, 2.17.4 i 2.18.1, uwierzytelniony użytkownik z uprawnieniami do tworzenia lub modyfikowania procesów roboczych mógł osiągnąć globalne zanieczyszczenie prototypu za pomocą węzła XML, co prowadziło do zdalnego wykonania kodu (RCE) w połączeniu z innymi węzłami wykorzystującymi to zanieczyszczenie. Problem został naprawiony w wersjach 1.123.32, 2.17.4 i 2.18.1.

W n8n przed wersją 2.29.8 oraz 2.30.x przed 2.30.1 w pakiecie @n8n/computer-use nie są egzekwowane ograniczenia sandboksowania powłoki na systemach Linux i Windows (sandboksowanie działało tylko na macOS). Polecenia powłoki wykonywane przez narzędzie działają bez żadnych ograniczeń systemu plików ani sieci, umożliwiając nieograniczony dostęp do systemu plików hosta i sieci z poziomu procesu agenta computer-use. Problem dotyczy tylko wdrożeń, w których pakiet @n8n/computer-use jest jawnie zainstalowany i uruchomiony; standardowe instalacje n8n nie są zagrożone.

n8n w wersjach przed 2.20.0 zawiera podatność na wyciek poświadczeń w punkcie końcowym POST /rest/dynamic-node-parameters/options, co pozwala uwierzytelnionym użytkownikom na obejście ograniczeń dotyczących dozwolonych domen żądań HTTP. Atakujący z dostępem do poświadczeń mogą zmusić serwer n8n do wysyłania żądań HTTP z poświadczeniami do nieautoryzowanych hostów.

n8n to platforma automatyzacji procesów, która przed wersjami 1.123.32, 2.17.4 i 2.18.1 była podatna na atak nieautoryzowanego użytkownika, który mógł zarejestrować złośliwego klienta OAuth. Po autoryzacji przez ofiarę, złośliwy skrypt mógł zostać wykonany w sesji przeglądarki ofiary.

W n8n, platformie automatyzacji przepływów pracy open source, wykryto dodatkowe luki w ewaluacji wyrażeń. Uwierzytelniony użytkownik z uprawnieniami do tworzenia lub modyfikowania przepływów pracy może wykorzystać spreparowane wyrażenia do nieautoryzowanego wykonania poleceń systemowych na hoście.

W n8n (wersje 0.121.2 i niższe) uwierzytelniony atakujący może wykonać złośliwy kod za pomocą usługi n8n. Może to prowadzić do pełnej kompromitacji i wpływać zarówno na instancje self-hosted, jak i n8n Cloud. Problem naprawiono w wersji 1.121.3. Administratorzy mogą zmniejszyć ryzyko, wyłączając węzeł Git i ograniczając dostęp dla niezaufanych użytkowników, ale zaleca się aktualizację do najnowszej wersji.

W n8n (wersje od 1.65.0 do 1.121.0) atakujący może uzyskać dostęp do plików na serwerze poprzez wykonanie niektórych formularzowych przepływów pracy. Podatny przepływ pracy może przyznać dostęp nieuwierzytelnionemu zdalnemu atakującemu, co prowadzi do ujawnienia wrażliwych informacji przechowywanych w systemie i może umożliwić dalszą kompromitację w zależności od konfiguracji wdrożenia i użycia przepływów. Problem naprawiono w wersji 1.121.0.

n8n w wersjach od 1.0.0 do przed 2.0.0 zawiera podatność na obejście sandboxa w Python Code Node używającym Pyodide. Uwierzytelniony użytkownik z uprawnieniami do tworzenia lub modyfikowania workflow może wykorzystać tę podatność do wykonania dowolnych poleceń na systemie hosta, na którym działa n8n, z uprawnieniami procesu n8n.

n8n przed wersją 2.34.1 oraz 2.33.x przed 2.33.4 zawiera obejście ochrony SSRF w narzędziu SearXNG Agent. Narzędzie wysyłało żądania do podanego przez użytkownika adresu API za pomocą surowego klienta HTTP, który nie przechodził przez scentralizowaną ochronę SSRF n8n. Na instancjach z włączoną opcją N8N_SSRF_PROTECTION_ENABLED=true, uwierzytelniony użytkownik z uprawnieniami do tworzenia poświadczeń SearXNG i konfigurowania osobistego agenta mógł ustawić adres API na wewnętrzny host, powodując połączenie serwera n8n z tym hostem i zwrócenie treści odpowiedzi przez czat agenta.

n8n przed wersją 1.123.69 (oraz 2.x przed 2.33.4 / 2.34.1) zawiera podatność na wykonanie kodu w węźle Git. Węzeł Git wykonywał pewne wartości konfiguracyjne git specyficzne dla repozytorium bez ich neutralizacji, więc każda kolejna operacja węzła Git na repozytorium zawierającym złośliwą wartość wykonywała ją jako użytkownik procesu n8n. Nie jest to osiągalne przez własne kontrolki konfiguracyjne węzła Git i wymaga oddzielnej podatności na zapis pliku gdzie indziej, aby umieścić złośliwą wartość.

n8n to platforma automatyzacji przepływów pracy. W wersjach przed 1.123.69, 2.33.4 i 2.34.1, piaskownica VM węzła JavaScript Code nie zamrażała Function.prototype piaskownicy, co pozwalało uwierzytelnionemu użytkownikowi z możliwością tworzenia i wykonywania przepływów pracy na jej zanieczyszczenie z poziomu wykonania węzła Code i odzyskanie odniesienia do globalThis hosta, co skutkowało ucieczką z piaskownicy. Pełny łańcuch ataku dodatkowo zależy od dostępności określonych modułów jako dozwolonych importów w konfiguracji wdrożenia. Problem został naprawiony w wersjach 1.123.69, 2.33.4 i 2.34.1.

n8n przed wersją 1.123.69, 2.x przed 2.33.4 oraz 2.34.x przed 2.34.1 zawiera podatność na odmowę usługi przez wyrażenia regularne (ReDoS) w węzłach Filter i Switch, które kompilują wzorce regex dostarczone przez użytkownika za pomocą new RegExp() i wykonują je synchronicznie na wątku roboczym bez walidacji złożoności ani limitu czasu wykonania. Złośliwy wzorzec regex może zablokować wątek roboczy na dłuższy czas na każdy przetwarzany element danych, opóźniając inne wykonania przepływów pracy na tym samym wątku.

n8n przed wersją 1.123.69, 2.x przed 2.33.4 oraz 2.x przed 2.34.1 zawiera obejście dozwolonych domen w węźle GraphQL. Gdy parametr Authentication węzła jest ustawiony na tryb wyrażenia, każdy selektor poświadczeń z ograniczeniami uwierzytelniania jest traktowany jako aktywny; jeśli dołączone są dwa poświadczenia różnych typów, węzeł egzekwuje politykę dozwolonych domen tylko dla pierwszego poświadczenia, jednocześnie dołączając materiały z obu. Uwierzytelniony użytkownik z uprawnieniami do tworzenia przepływów pracy może w ten sposób wysłać poświadczenie z ograniczeniem domeny do kontrolowanego przez atakującego punktu końcowego, eksfiltrując je z uprawnieniami wyciekniętego poświadczenia.

n8n przed wersjami 1.123.69, 2.33.4 i 2.34.1 zawiera podatność na dowolny odczyt i zapis plików w węźle Snowflake. Węzeł przekazuje bezpośrednio do SDK Snowflake dane wejściowe zapytania, w tym polecenia po stronie klienta, bez stosowania ograniczeń dostępu do plików n8n. Uwierzytelniony użytkownik z ważnymi poświadczeniami Snowflake może przesłać lokalny plik z hosta n8n lub nadpisać istniejący plik.

n8n przed wersjami 2.34.1 i 2.33.4 zawiera podatność na obejście autoryzacji w ścieżce usuwania niestandardowych ról projektowych z przeniesieniem. Kod sprawdzał tylko, czy rola docelowa istnieje i jest w zakresie projektu, bez przeprowadzania kontroli autoryzacji na poziomie projektu. Użytkownik posiadający tylko wąski zakres globalny role:manageProject może usunąć dowolną niestandardową rolę projektową i przypisać jej posiadaczy (w tym siebie) do wbudowanej roli project:admin, uzyskując pełną kontrolę administracyjną nad projektami.

n8n przed wersjami 1.123.69, 2.33.4 i 2.34.1 zawiera podatność na ucieczkę z piaskownicy VM w JavaScript task runner. Procedura zamrażania prototypów obejmuje funkcje globalne, ale nie wewnętrzne konstruktory modułów, takie jak EventEmitter, co pozwala uwierzytelnionemu użytkownikowi z dostępem do węzła Code wykorzystać zanieczyszczenie prototypu do wykonania dowolnych poleceń w kontenerze runnera. Zanieczyszczony prototyp jest obiektem procesowym, więc korupcja utrzymuje się między wykonaniami węzła Code innych dzierżawców na tym samym wspólnym runnerze. W wersjach v1.x bez włączonych task runnerów, JavaScript węzła Code działa bezpośrednio w głównym procesie n8n, gdzie wpływ może być większy.

n8n przed wersjami 1.123.69, 2.33.4 i 2.34.1 zawiera podatność na ujawnienie informacji w węźle GraphQL. Gdy żądanie GraphQL nie powiedzie się na poziomie połączenia, węzeł ponownie zgłasza błąd klienta HTTP bez zmian, zamiast opakować go w standardowy typ błędu n8n. Ten błąd zawiera nagłówki bieżącego żądania, w tym odszyfrowany sekret poświadczeń, który silnik wykonawczy zapisuje dosłownie. Każdy uwierzytelniony użytkownik, który może odczytać wynikowe wykonanie, może pobrać odszyfrowany sekret poświadczeń z zapisanych danych uruchomienia.

n8n przed wersjami 1.123.69, 2.33.4 i 2.34.1 zawiera podatność na wstrzyknięcie wyrażeń w renderowaniu podglądu linków pól resource-locator. Edytor wstawiał zapisaną wartość pola bezpośrednio do szablonu URL typu węzła bez sprawdzania składni wyrażeń. Uwierzytelniony członek może zapisać złośliwą wartość, tak że gdy inny użytkownik otworzy dotknięty węzeł w edytorze, wstrzyknięte wyrażenie zostanie wykonane jako JavaScript w sesji ofiary (wykonanie skryptu między użytkownikami).

n8n w wersjach przed 1.123.69 zawiera podatność na podrabianie żądań po stronie serwera (SSRF) w operacji Draw Text węzła Edit Image, która umożliwia uwierzytelnionym użytkownikom wstrzykiwanie prymitywów MVG. Atakujący mogą tworzyć złośliwe wartości tekstowe, aby wysyłać ślepe żądania HTTP do dowolnych adresów lub uzyskiwać dostęp do lokalnych plików.

n8n w wersjach przed 2.34.1 zawiera obejście walidacji poświadczeń w narzędziu MCP create_workflow_from_code, gdy typ uwierzytelniania jest ustawiony na wyrażenie. Atakujący z ważnym kluczem API MCP Bearer i znajomością docelowego ID poświadczeń mogą utrwalać nieautoryzowane referencje poświadczeń między projektami w przepływach pracy w różnych projektach.

n8n przed wersjami 1.123.69, 2.33.4 i 2.34.1 zawiera podatność na trwałe cross-site scripting (XSS) w stronie ukończenia węzła Form. Strona ukończenia stosowała politykę bezpieczeństwa treści (CSP) tylko wtedy, gdy respondWith nie było ustawione na 'redirect', ale responseText zawsze był renderowany jako surowy HTML. Uwierzytelniony członek mógł ustawić respondWith na 'redirect' za pomocą wyrażenia, zachowując wypełniony responseText, co powodowało, że strona ukończenia serwowała nieprzesanizowany HTML i skrypt z pochodzenia n8n. Każdy odwiedzający, który przesłał wynikający z tego publiczny formularz, miałby ten skrypt wykonany w tym samym pochodzeniu z jego sesją.

n8n przed wersjami 1.123.69, 2.33.4 i 2.34.1 zawiera podatność na wstrzyknięcie filtra PostgREST w operacjach Row Get Many, Delete i Update węzła Supabase, które budowały zapytania filtrów przez konkatenację wartości możliwej do wiązania wyrażeń bez escapowania. Atakujący mógł wstrzyknąć warunek, który rozszerzał filtr tak, aby pasował do każdego wiersza, zamieniając zamierzoną operację na pojedynczym wierszu w ujawnienie, usunięcie lub modyfikację całej tabeli.

n8n przed wersjami 1.123.69, 2.33.4 i 2.34.1 zawiera podatność na wstrzyknięcie NoSQL w operacjach Find, Delete i Aggregate węzła MongoDB, które parsują parametr Query jako JSON po rozwiązaniu wyrażeń bez sanityzacji operatorów MongoDB. Atakujący, który może wpłynąć na rozwiązane zapytanie (np. przez dane kontrolowane zewnętrznie), może wstrzyknąć operatory takie jak $ne lub $where, zamieniając zamierzone wyszukiwanie pojedynczego dokumentu w ujawnienie całej kolekcji, usunięcie całej kolekcji lub inne operacje na serwerze bazy danych.

Podatność w n8n (przed 1.123.69, 2.33.4 i 2.34.1) to obejście ochrony SSRF w wymianie kodu autoryzacyjnego OAuth2 na token dostępu. Token exchange używa osobnego klienta HTTP bez zabezpieczeń SSRF, co pozwala użytkownikowi z uprawnieniami do tworzenia poświadczeń na ustawienie adresu URL tokenu na adres wewnętrzny i wykonanie żądania POST do tego celu, a odpowiedź jest odsyłana do atakującego.

n8n przed wersjami 2.33.4 i 2.34.x przed 2.34.1 zawiera podatność na zdalne wykonanie kodu w loaderze schematów węzłów @n8n/workflow-sdk używanym do ładowania schematów węzłów MCP. Loader wyprowadza ścieżkę modułu schematu węzła bezpośrednio z dostarczonego przez atakującego ciągu typu węzła bez walidacji sekwencji przejść ścieżek. Uwierzytelniony użytkownik z uprawnieniami global:member może odwołać się do złośliwych plików przez przejście ścieżek, powodując wykonanie kodu w głównym procesie n8n.

W resolverze scanFeedsResolver w aplikacji (prawdopodobnie n8n) brakuje walidacji adresu URL, co pozwala uwierzytelnionemu użytkownikowi kierować serwer do dowolnych wewnętrznych punktów końcowych. Odpowiedź jest parsowana jako kanał RSS/Atom lub HTML, co ogranicza ujawnienie do metadanych kanału i linków do RSS/Atom, ale pozwala odróżnić dostępne porty od niedostępnych.

W n8n, platformie automatyzacji przepływów pracy, przed wersjami 1.123.64, 2.29.8 i 2.30.1, operacja klonowania węzła Git pozwala uwierzytelnionemu użytkownikowi przepływu pracy na podmianę zweryfikowanego katalogu na dowiązanie symboliczne przed klonowaniem, co umożliwia umieszczenie spreparowanego repozytorium w katalogu węzłów społeczności, które po restarcie ładuje się jako niestandardowy węzeł JavaScript i wykonuje dowolny kod na serwerze.

n8n przed wersjami 1.123.67, 2.31.5 i 2.32.1 zawiera podatność na wstrzykiwanie SQL w węźle PostgresTrigger, który interpoluje parametry identyfikatorów dostarczanych przez użytkownika (nazwy kanału, funkcji i wyzwalacza) do zapytań SQL bez odpowiedniego escapowania. Uwierzytelniony użytkownik może wstrzyknąć dowolny kod SQL wykonywany na połączonej bazie PostgreSQL z uprawnieniami skonfigurowanego poświadczenia, umożliwiając pełny odczyt i zapis.

n8n przed wersjami 2.31.5 i 2.32.x przed 2.32.1 zawiera obejście ograniczeń ścieżki w narzędziu @n8n/computer-use file-search (search_files). Złośliwy wzorzec wyszukiwania może ominąć sprawdzenie ograniczenia katalogu bazowego i rozszerzyć się na lokalizacje poza skonfigurowanym katalogiem, co powoduje, że narzędzie zwraca nazwy i zawartość dowolnych lokalnych plików czytelnych dla użytkownika systemowego demona. Każde wdrożenie, w którym aktor może wpływać na dane wejściowe wyszukiwania, jest dotknięte.

Podatność w n8n przed wersją 2.32.1 polega na braku egzekwowania listy dozwolonych domen (Allowed HTTP Request Domains) w wielu węzłach AI i LLM, gdy skonfigurowane są adresy URL bazowe lub końcowe dostarczone przez użytkownika. Użytkownicy z niskimi uprawnieniami, edytujący przepływy pracy z dostępem tylko do użycia współdzielonych poświadczeń, mogą przekierować żądania na hosty kontrolowane przez atakującego i eksfiltrować sekrety poświadczeń w celu ponownego użycia przeciwko usługom bazowym.

Podatność w n8n przed wersją 1.123.67 zawiera podatność na przechodzenie po ścieżkach (path traversal) w operacjach fetch, pull i push-tags węzła Git, co pozwala uwierzytelnionym użytkownikom na obejście kontroli ograniczeń ścieżek repozytorium. Atakujący z prawami tworzenia/wykonywania przepływów pracy mogą wskazać dozwolone zdalne konfiguracje na lokalne ścieżki poza piaskownicą, aby pobrać dowolne repozytoria git i odczytać ich pliki oraz historię.

n8n przed wersją 2.32.1 zawiera podatność na obejście ochrony przed SSRF w węźle MCP Client, która pozwala uwierzytelnionym użytkownikom ominąć zabezpieczenia SSRF. Atakujący mogą tworzyć przepływy pracy, które wysyłają żądania do wewnętrznych lub zablokowanych hostów bez przechodzenia przez ochronę SSRF, ujawniając wewnętrzne usługi i odczytując odpowiedzi z powrotem przez przepływ pracy.

Podatność w n8n przed wersjami 1.123.67, 2.31.5 i 2.32.1 zawiera podatność na pomylenie typów (type confusion) w węźle Send Email, który nie egzekwuje, aby pola wiadomości były ciągami znaków. Spreparowana wartość niebędąca ciągiem, dostarczona z wyrażenia przepływu pracy do pola tekstowego lub HTML, może być zinterpretowana przez bibliotekę pocztową (Nodemailer) jako ścieżka pliku lub URL, umożliwiając ujawnienie dowolnych plików lokalnych i SSRF. Wymaga to istniejącego aktywnego przepływu pracy z nieuwierzytelnionym webhookiem, prawidłowych poświadczeń SMTP i nieufnego wejścia mapowanego bezpośrednio do pola treści; nie jest to konfiguracja domyślna.

Podatność w n8n przed wersjami 2.31.5 i 2.32.1 umożliwia ucieczkę z piaskownicy w ocenie wyrażeń. Uwierzytelniony użytkownik z uprawnieniami do tworzenia lub modyfikowania przepływów pracy może tworzyć wyrażenia używające ciał funkcji strzałkowych, aby obejść piaskownicę wyrażeń, co prowadzi do wykonania poleceń systemowych na hoście, na którym działa n8n. Problem został naprawiony w wersjach 2.31.5 i 2.32.1.

Podatność w n8n przed wersjami 1.123.67, 2.31.5 i 2.32.1 polega na tym, że walidacja dostępu do poświadczeń dotyczy tylko poświadczeń najwyższego poziomu węzła, a nie poświadczeń odwołanych w węźle Execute Sub-workflow w osadzonym JSON. Członek z prawem edytora do współdzielonego przepływu pracy (gdy udostępnianie jest włączone), znający ID poświadczeń, może odwołać się do nich w osadzonym JSON; przechodzi to walidację przy zapisie i wykonaniu oraz rozwiązuje się w kontekście projektu nadrzędnego, umożliwiając użycie lub eksfiltrację poświadczeń, do których nie ma uprawnień.

n8n przed wersjami 1.123.67, 2.31.5 i 2.32.1 zawiera podatność na wstrzykiwanie SQL w węźle Snowflake w operacji Execute Query, która interpoluje wartości wyrażeń bezpośrednio do ciągu SQL. Gdy autor przepływu pracy osadza niezaufane, zewnętrznie kontrolowane dane wyrażeń bezpośrednio w surowym zapytaniu SQL, dane te nie są parametryzowane, co umożliwia wstrzykiwanie SQL. Poprawka dodaje opcjonalne pole 'Query Parameters' do wiązania wartości za pomocą symboli zastępczych pozycyjnych.

Podatność w n8n przed wersjami 1.123.67, 2.31.5 i 2.32.1 zawiera podatność na zanieczyszczenie prototypu (prototype pollution) w węźle Edit Fields (Set). Węzeł przypisuje pola wyjściowe przez setter ścieżek z notacją kropkową bez ograniczania nazwy pola, co pozwala uwierzytelnionemu użytkownikowi nazwać pole po odziedziczonej ścieżce wbudowanej metody i uszkodzić współdzielony globalny obiekt w głównym procesie Node.js. Ponieważ ten globalny obiekt jest używany na ścieżce uwierzytelniania żądań, instancja następnie odrzuca każde uwierzytelnione żądanie, powodując awarię całej instancji dla wszystkich użytkowników do czasu ponownego uruchomienia procesu.

n8n w wersjach przed 1.123.64, 2.29.8 i 2.30.1 zawiera podatność ujawnienia poświadczeń. Przy konfiguracji z kluczem konta usługi Google, pełny prywatny klucz PEM został błędnie umieszczony w polu kid nagłówka JWT (przeznaczonym tylko dla identyfikatora klucza). Ponieważ nagłówki JWT są kodowane Base64, a nie szyfrowane, klucz prywatny może zostać odzyskany przez każdego, kto loguje lub inspekcjonuje JWT.

n8n przed wersjami 1.123.64, 2.29.8 i 2.30.1 zawiera warunek wyścigu TOCTOU w operacji klonowania węzła Git, który umożliwia uwierzytelnionym użytkownikom ominięcie ograniczeń ścieżki poprzez zamianę katalogu na dowiązanie symboliczne po walidacji ścieżki, ale przed wykonaniem klonowania. Pozwala to atakującemu umieścić spreparowane repozytorium w katalogu węzłów społeczności, które n8n ładuje jako niestandardowy węzeł przy następnym restarcie, wykonując dowolny JavaScript na serwerze. Dotyczy to zarówno instancji samodzielnie hostowanych, jak i chmurowych.

n8n przed wersjami 1.123.64, 2.x przed 2.29.8 i przed 2.30.1 zawiera podatność na DOM-based cross-site scripting w podglądzie HTML, który renderuje dane wyjściowe wykonania w iframe srcdoc bez atrybutu sandbox. Ominięcie sanitizera pozwala na wykonanie wstrzykniętego skryptu w tym samym originie co edytor. Gdy ofiara otworzy podgląd, skrypt może wywoływać uwierzytelnione API przy użyciu sesji ofiary. Konto z uprawnieniami global:member może wykorzystać ten problem.

n8n przed wersjami 1.123.64, 2.29.8 i 2.30.1 nie egzekwuje ograniczenia "Allowed HTTP Request Domains" dla poświadczeń HTTP (Header Auth, Basic Auth, Query Auth, OAuth) w węźle GraphQL, w przeciwieństwie do węzła HTTP Request. Uwierzytelniony użytkownik mogący tworzyć lub edytować workflowy może skierować endpoint węzła na kontrolowany serwer i wyeksfiltrować ograniczone poświadczenia. Dotyczy to instancji, gdzie poświadczenie ma skonfigurowane "Allowed HTTP Request Domains" i jest dostępne dla niebędących właścicielami.

W n8n przed wersjami 2.30.1 i 2.29.8, podczas wymiany tokenów JWT, nadawane są wszystkie zakresy uprawnień klucza API, niezależnie od roli użytkownika. Niskouprzywilejowany użytkownik posiadający ważny zewnętrzny JWT może uzyskać token dostępu umożliwiający operacje administracyjne, w tym eskalację roli, tworzenie i usuwanie użytkowników, a przy włączonej instalacji niezweryfikowanych pakietów społecznościowych – zdalne wykonanie kodu.

n8n przed wersjami 2.29.8 i 2.30.1 (od wersji 2.27.0) nie weryfikuje, czy uwierzytelniony użytkownik ma dostęp do workflowu wskazanego jako zasób OAuth. Użytkownik na poziomie członka może zarejestrować klienta OAuth, zatwierdzić zgodę dla workflowu innego użytkownika i uzyskać ważny token. Workflow działa w kontekście właściciela z jego poświadczeniami.