Podatności n8n

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

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

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.

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

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

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

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

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.

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

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

n8n w wersjach przed 1.123.64, 2.29.8 i 2.30.1 zawiera podatność na fałszowanie żądań po stronie serwera (SSRF) w endpointach dynamic-node-parameters, które nie mają zakresów autoryzacji. Uwierzytelniony atakujący może podać bezwzględne adresy URL w konfiguracji routingu, aby ominąć ograniczenia baseURL i zmusić serwer n8n do wysyłania żądań HTTP do dowolnych wewnętrznych celów, gdy ochrona SSRF jest wyłączona.

n8n przed wersjami 1.123.64, 2.29.8 i 2.30.1 zawiera podatność na przechowywane DOM cross-site scripting w komponencie Resource Locator, który przekazuje parametr cachedResultUrl utrwalony w przepływie pracy do funkcji window.open() bez walidacji schematu. Atakujący z uprawnieniami do tworzenia/edycji przepływów pracy może stworzyć przepływ pracy ze złośliwym schematem (np. javascript:) w cachedResultUrl; gdy ofiara otworzy spreparowany przepływ pracy i wejdzie w interakcję z zewnętrznymi linkami, ładunek wykonuje się w przeglądarce ofiary.

n8n zawiera podatność na ominięcie sanitizera w handlerze computed-member starszego ewaluatora wyrażeń. Uwierzytelniony użytkownik z uprawnieniami do tworzenia lub modyfikowania przepływów pracy może stworzyć złośliwe wyrażenie, aby ominąć sanitizer i osiągnąć wykonanie kodu na poziomie hosta jako proces n8n. Starszy silnik wyrażeń jest domyślny w dotkniętych wersjach. Naprawione w n8n 1.123.64, 2.29.8 i 2.30.1.

W n8n przed wersją 1.123.64 nie są prawidłowo maskowane poświadczenia niestandardowych nagłówków HTTP w danych wykonania podwęzła LLM, co powoduje zapisywanie kluczy API i sekretów w postaci jawnego tekstu w rekordach wykonania przepływu pracy. Uwierzytelnieni użytkownicy z dostępem do danych wykonania mogą odczytać te poświadczenia.

Podatność eskalacji uprawnień w n8n przed wersjami 1.123.64, 2.29.8 i 2.30.1 w Enterprise SSO. Atakujący może uzyskać rolę global:owner, co daje pełną kontrolę administracyjną.

W n8n przed wersją 2.30.1, funkcja AI Agents ma lukę w autoryzacji, która pozwala użytkownikowi z rolą Project Viewer na eskalację uprawnień poprzez rozmowę z agentem mającym włączone narzędzia węzłów, co umożliwia wykonanie dowolnych węzłów i dostęp do sekretów poświadczeń.

W n8n przed wersją 2.28.0 (oraz przed 2.27.4 w gałęzi 2.27.x) endpoint DELETE /${restEndpoint}/test-webhook/:id jest rejestrowany przed zastosowaniem middleware uwierzytelniającego, co pozwala każdemu nieuwierzytelnionemu wywołującemu sieciowemu, który zna identyfikator przepływu pracy, na anulowanie aktywnej rejestracji testowego webhooka tego przepływu. Wpływ jest ograniczony do zakłócania trwających sesji testowych; produkcyjne webhooki, trwały stan przepływu pracy i przechowywane dane nie są zagrożone.

Podatność w n8n przed wersjami 1.123.61, 2.27.4 i 2.28.1 umożliwia ominięcie uprawnień w obsłudze zewnętrznych sekretów. Uwierzytelniony użytkownik z uprawnieniami do tworzenia lub aktualizacji poświadczeń, ale bez zakresu externalSecret:list, może osadzić odniesienia do zewnętrznych sekretów w poświadczeniach, które nie są wykrywane przez statyczną walidację, a następnie są rozwiązywane podczas wykonania przepływu pracy, ujawniając wartości sekretów.

W n8n przed wersją 2.28.1 wykryto podatność na ujawnienie informacji, w której zewnętrzne sekrety są nieprawidłowo rozwiązywane w wyrażeniach węzłów przepływu pracy poza zakresem poświadczeń. Uwierzytelnieni edytorzy projektu mogą odczytać jawne wartości zewnętrznych sekretów, odwołując się do nich w wyrażeniach węzłów bez wymaganych uprawnień dostępu do sekretów.

Podatność w n8n umożliwia ominięcie uwierzytelniania w węźle Chat Trigger, gdy skonfigurowane jest uwierzytelnianie użytkownika (konfiguracja nie domyślna). W wersjach przed 1.123.22, w linii 2.0.0 do 2.9.2 oraz w wersji 2.10.0, sprawdzanie uwierzytelniania na punkcie końcowym webhooka Chat Trigger może zostać obejście, co pozwala na dostęp bez ważnych poświadczeń.

Podatność w n8n przed wersją 2.19.3 pozwala na ominięcie ograniczeń dostępu do plików w legacy węźle ExecuteWorkflow. Uwierzytelniony użytkownik z uprawnieniami do tworzenia lub modyfikowania workflowów może podać dowolną ścieżkę pliku, co umożliwia sprawdzenie istnienia plików na hoście oraz, w przypadku pliku JSON z workflowem, jego załadowanie i wykonanie.

W n8n przed wersją 2.10.0 wykryto podatność w węźle Guardrail, która umożliwia atakującym ominięcie domyślnych instrukcji zabezpieczających. Użytkownicy końcowi mogą tworzyć złośliwe dane wejściowe, aby obejść ochronę Guardrail i naruszyć integralność przepływów pracy.

Podatność w n8n przed wersją 2.28.0 (oraz przed 1.123.58 w gałęzi 1.x) umożliwia wyczerpanie miejsca na dysku poprzez endpoint uploadu plików w tabeli danych. Mechanizm limitu na żądanie nie uwzględnia plików już zapisanych do współdzielonego katalogu tymczasowego, co pozwala uwierzytelnionemu użytkownikowi na wielokrotne przesyłanie plików, które kumulują się na dysku do czasu okresowego czyszczenia.

W n8n przed wersjami 1.123.24, 2.10.4 i 2.12.0 wykryto podatności na cross-site scripting (XSS) oraz otwarte przekierowania w węźle Form Node. Problemy wynikają z niesanityzowanych pól opisu HTML oraz zbyt liberalnych zasad sandboksa iframe.

W n8n przed wersjami 1.123.61, 2.27.4 i 2.28.1 uwierzytelniony członek z dostępem tylko do edycji współdzielonego przepływu pracy mógł odczytać nagłówki z danymi uwierzytelniającymi ujawnione przez obiekt $request w węźle HTTP Request i wyeksfiltrować sekret przez dane elementu.

W n8n przed wersjami 2.27.4 i 2.28.1, przy skonfigurowaniu więcej niż jednego zaufanego wystawcy tokenów, tożsamości zewnętrzne były mapowane na konta lokalne wyłącznie na podstawie roszczenia sub (subject) z JWT, ignorując roszczenie iss (issuer). Pozwalało to atakującemu posiadającemu ważny token od jednego zaufanego wystawcy, z sub pasującym do ofiary u innego wystawcy, na uwierzytelnienie się jako ta ofiara.

W n8n przed wersjami 2.27.4 i 2.28.1 funkcja AI Agents nie egzekwowała ograniczenia Allowed HTTP Request Domains skonfigurowanego w poświadczeniach, gdy narzędzie MCP wskazywało na dowolny URL. Umożliwiło to użytkownikowi z poziomem członka i dostępem tylko do używania współdzielonego poświadczenia wysłanie jego sekretu na zewnętrzny serwer kontrolowany przez atakującego.

W n8n, platformie automatyzacji przepływów pracy open source, przed wersjami 1.123.61, 2.27.4 i 2.28.1 uwierzytelniony użytkownik z domyślnym uprawnieniem workflow:create mógł zanieczyścić Object.prototype poprzez spreparowany przepływ pracy zapisany, zaktualizowany lub zaimportowany za pomocą API przepływów pracy. Umożliwiało to traktowanie nieuwierzytelnionych żądań jako uprzywilejowanego użytkownika i ujawniało punkty końcowe listy użytkowników i projektów.

Podatność SQL injection w n8n przed wersjami 1.123.61, 2.x przed 2.27.4 oraz 2.28.x przed 2.28.1 występuje w legacy węźle MySQL v1 podczas operacji executeQuery. Wartości z wyrażeń {{ ... }} są podstawiane bezpośrednio do surowego zapytania SQL bez parametryzacji, co umożliwia atakującemu wstrzyknięcie dowolnego kodu SQL przez dane wejściowe docierające do tych wyrażeń, gdy przepływ pracy jest podłączony do zewnętrznie dostępnego wyzwalacza (np. Webhook).

W n8n przed wersją 2.28.0 wykryto podatność polegającą na nieprawidłowej autoryzacji, która umożliwia uwierzytelnionym użytkownikom przypisywanie przepływów pracy do folderów w innych projektach. Atakujący mogą ominąć granice autoryzacji projektu i folderu, wysyłając spreparowane żądania podczas tworzenia przepływu pracy, co prowadzi do naruszenia integralności logicznej struktury folderów w docelowym projekcie.

Podatność w n8n przed wersjami 2.25.7 i 2.26.x przed 2.26.2 umożliwia ominięcie autoryzacji w punkcie końcowym ponawiania wykonań Public API. Uwierzytelniony użytkownik z dostępem tylko do odczytu do współdzielonego workflow może ponawiać jego wykonania, wykorzystując zakres workflow:read zamiast wymaganego workflow:execute.

Podatność w n8n przed wersjami 1.123.55, 2.25.7 i 2.26.2 umożliwia ominięcie autoryzacji w punkcie końcowym POST /workflows/{workflowId}/test-runs/new. Zamiast wymaganego zakresu workflow:execute używany jest workflow:read, co pozwala uwierzytelnionemu użytkownikowi z dostępem tylko do odczytu na uruchomienie testowego wykonania przepływu pracy.