Co znajdziesz w tym artykule?
- 1 Wprowadzenie do problemu / definicja luki
- 2 W skrócie
- 3 Kontekst / historia / powiązania
- 4 Analiza techniczna / szczegóły luki
- 5 Praktyczne konsekwencje / ryzyko
- 6 Rekomendacje operacyjne / co zrobić teraz
- 7 Różnice / porównania z innymi przypadkami (jeśli dotyczy)
- 8 Podsumowanie / kluczowe wnioski
- 9 Źródła / bibliografia
Wprowadzenie do problemu / definicja luki
n8n to popularna platforma do automatyzacji workflow (często także dla integracji z narzędziami AI/LLM), którą organizacje uruchamiają zarówno w chmurze, jak i w modelu self-hosted. Problem zaczyna się wtedy, gdy „niezaufana” logika użytkownika (wyrażenia JavaScript i fragmenty kodu Python w węzłach workflow) jest wykonywana w środowisku, które ma być odseparowane od hosta – ale w praktyce da się z tej piaskownicy uciec.
W dniach 27–28 stycznia 2026 opisano dwa takie przypadki: CVE-2026-1470 (krytyczna, CVSS 9.9) oraz CVE-2026-0863 (wysoka, CVSS 8.5). Obie luki pozwalają uwierzytelnionemu użytkownikowi z uprawnieniami do tworzenia/edycji workflow doprowadzić do zdalnego wykonania kodu (RCE) i przejęcia instancji – a w pewnych konfiguracjach nawet hosta.
W skrócie
- CVE-2026-1470 (CVSS 9.9, Critical): ucieczka z sandboxa w silniku wyrażeń (Expression Engine) poprzez obejście walidacji AST w JavaScript; finalnie prowadzi do RCE w głównym procesie n8n.
- CVE-2026-0863 (CVSS 8.5, High): ucieczka z sandboxa dla Python Code node (zwłaszcza w trybie Internal) z wykorzystaniem zachowania wyjątków w Python 3.10+; w „Internal” może skutkować przejęciem całej instancji na hoście.
- Dotyczy głównie self-hosted (n8n cloud ma mieć poprawki wdrożone), a kluczowe jest szybkie przejście na wersje naprawione.
Kontekst / historia / powiązania
W praktyce n8n działa jak „centralny węzeł automatyzacji” – ma dostęp do webhooków, sekretów, tokenów API, systemów IAM, narzędzi DevOps i danych biznesowych. To sprawia, że nawet „tylko” post-auth RCE jest bardzo groźne: użytkownik o pozornie ograniczonych prawach (np. edycja workflow) może stać się punktem wejścia do przejęcia infrastruktury.
Badacze JFrog podkreślają, że mimo wzmacniania mechanizmów ochronnych w n8n, złożone cechy języków dynamicznych (JS/Python) i zmiany zachowań runtime potrafią rozbić założenia sandboxa.
Analiza techniczna / szczegóły luki
CVE-2026-1470: JavaScript „Expression Engine” i pominięty edge-case with
Mechanizm wyrażeń n8n opiera się na wykonywaniu treści {{ ... }} poprzez konstruktor JavaScript Function, co z natury jest ryzykowne. Dlatego n8n stosuje AST-based sandbox (m.in. walidacje i neutralizację niebezpiecznych konstrukcji). JFrog opisuje jednak, że jeden problematyczny element został przeoczony: instrukcja with (przestarzała, ale wciąż wspierana), która zmienia sposób rozwiązywania identyfikatorów w zakresie. Skutkiem jest możliwość „oszukania” walidacji AST tak, by obejść blokady i doprowadzić do uruchomienia dowolnego kodu w kontekście głównego procesu n8n.
Dlaczego CVSS aż 9.9 mimo wymogu logowania? Bo wykonanie następuje na głównym node n8n, co daje realnie pełne przejęcie instancji (a często i hosta) przy niskim progu uprawnień (wystarczy możliwość edycji workflow).
CVE-2026-0863: Python Code node, AST sandbox i „ucieczka przez wyjątki” (Python 3.10+)
Druga luka dotyczy wykonywania Pythona w Code node i obejścia restrykcji sandboxa (opartego o analizę AST, denylisty builtins/importów itp.). Kluczowy element to fakt, że od Python 3.10 obiekty wyjątków typu AttributeError zyskały dodatkowe pola (m.in. obj), co może zostać wykorzystane do odzyskania referencji do obiektów, które sandbox próbował ukryć. W efekcie, przy sprytnym łańcuchu działań (bez potrzeby klasycznych, wprost zakazanych wywołań), możliwe staje się obejście ograniczeń i dojście do wykonania poleceń systemowych.
Bardzo ważne jest tu rozróżnienie trybów uruchomienia:
- Internal mode: task runner jest procesem potomnym n8n (ta sama tożsamość/UID/GID), co zwiększa skutki kompromitacji.
- External mode: kod wykonuje się w sidecarze (oddzielny kontener/runner), co zwykle ogranicza wpływ na hosta (choć nadal jest to poważny incydent).
Praktyczne konsekwencje / ryzyko
Jeśli atakujący ma konto (lub przejmie konto) z uprawnieniami do tworzenia/edycji workflow, może:
- uzyskać RCE i przejąć instancję n8n (a przez to dostęp do sekretów, tokenów, połączeń z systemami firmy),
- modyfikować workflow w celu trwałej persystencji (np. „ciche” eksfiltracje lub dalsze skrypty),
- wykonać ruch boczny (lateral movement) do narzędzi, które n8n integruje (CI/CD, chmura, SaaS, IAM).
W konfiguracjach Internal mode ryzyko jest szczególnie wysokie, bo udana ucieczka z sandboxa oznacza wykonywanie komend w kontekście głównego środowiska n8n. Sama dokumentacja n8n ostrzega, że internal w produkcji to ryzyko bezpieczeństwa i zaleca external.
Rekomendacje operacyjne / co zrobić teraz
- Zaktualizuj n8n do wersji z poprawkami:
- dla CVE-2026-1470: 1.123.17 / 2.4.5 / 2.5.1 (lub nowsze)
- dla CVE-2026-0863: 1.123.14 / 2.3.5 / 2.4.2 (lub nowsze)
- Wymuś „External mode” dla task runners (szczególnie jeśli korzystasz z Code node) – to domyślna rekomendacja do produkcji, bo zapewnia izolację przez sidecar/runner.
- Ogranicz uprawnienia do tworzenia/edycji workflow (RBAC/least privilege): traktuj je jak uprawnienia „prawie administracyjne”, bo w razie luki sandboxowej to realny wektor przejęcia.
- Segmentacja i ograniczenia sieciowe: jeśli n8n musi mieć dostęp do systemów wewnętrznych, ogranicz to listami dozwolonych adresów/usług; rozważ osobne środowiska dla automatyzacji „wysokiego zaufania”.
- Rotacja sekretów po aktualizacji, jeśli istnieje podejrzenie nadużycia (tokeny API, hasła integracji, klucze chmurowe). W przypadku RCE zakładaj kompromitację poufności.
- Monitoring: wykrywaj nietypowe modyfikacje workflow (nowe węzły Code/Expression, zmiany w webhookach, nowe integracje), skoki w uruchomieniach i nieoczekiwane połączenia wychodzące.
Różnice / porównania z innymi przypadkami (jeśli dotyczy)
- JavaScript vs Python: w obu przypadkach problemem jest zaufanie do AST-based sandbox i to, że drobne szczegóły języka/runtime mogą stworzyć „furtkę” poza założony model bezpieczeństwa.
- Wpływ konfiguracji: CVE-2026-0863 wyraźnie eskaluje w Internal mode, podczas gdy external (sidecar) może ograniczać zasięg skutków.
- Wspólny mianownik: atak wymaga co prawda uwierzytelnienia, ale w realnych środowiskach „edytor workflow” to częsta rola operacyjna – a n8n bywa wystawiane w sieci firmowej (czasem też publicznie), co podnosi ryzyko.
Podsumowanie / kluczowe wnioski
CVE-2026-1470 i CVE-2026-0863 to kolejny sygnał, że sandboxowanie JavaScript i Pythona w produktach automatyzacji jest wyjątkowo trudne do „domknięcia” na stałe. W praktyce bezpieczeństwo n8n zależy nie tylko od patchy, ale też od modelu uruchomienia (external vs internal) oraz od tego, komu dajemy możliwość edycji workflow.
Jeśli masz self-hosted n8n: patchuj pilnie, przełącz na external mode dla task runners i potraktuj uprawnienia do workflow jako zasób krytyczny.
Źródła / bibliografia
- BleepingComputer – opis CVE-2026-1470 i CVE-2026-0863, wersje naprawione, kontekst zagrożenia (28 stycznia 2026). (BleepingComputer)
- JFrog Security Research – szczegóły techniczne obejść sandboxa (27 stycznia 2026). (research.jfrog.com)
- National Vulnerability Database (NVD) – karty CVE-2026-1470 i CVE-2026-0863 (metryki, opis, wektory). (NVD)
- Dokumentacja n8n – task runners, tryby internal/external i ostrzeżenie dot. produkcji. (docs.n8n.io)
- The Hacker News – podsumowanie, zalecane wersje aktualizacji i akcent na ryzyko w trybie internal. (The Hacker News)