CVE-2026-65589

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.