Krytyczna luka w n8n: CVE-2025-68668 (CVSS 9.9) pozwala zalogowanemu użytkownikowi wykonywać polecenia systemowe - Security Bez Tabu

Krytyczna luka w n8n: CVE-2025-68668 (CVSS 9.9) pozwala zalogowanemu użytkownikowi wykonywać polecenia systemowe

Wprowadzenie do problemu / definicja luki

Na początku stycznia 2026 r. nagłośniono krytyczną podatność w n8n (open-source’owej platformie automatyzacji workflow), która może doprowadzić do wykonania poleceń systemu operacyjnego na hoście. Luka ma identyfikator CVE-2025-68668 i ocenę CVSS 9.9 (Critical).

Istotne zastrzeżenie: atak wymaga uwierzytelnienia oraz uprawnień pozwalających tworzyć lub modyfikować workflow (czyli nie jest to typowy „unauth RCE z internetu”), ale w praktyce nadal bywa to scenariusz wysokiego ryzyka w środowiskach zespołowych i wieloużytkownikowych.

W skrócie

  • Co: sandbox bypass w Python Code Node opartym o Pyodide, skutkujący możliwością wykonania dowolnych komend na hoście.
  • Kto może zaatakować: zalogowany użytkownik z prawem edycji/tworzenia workflow.
  • Zakres wersji: n8n >= 1.0.0 i < 2.0.0.
  • Naprawa: aktualizacja do n8n 2.0.0.
  • Doraźne obejścia: m.in. wyłączenie Code Node / wyłączenie Pythona w Code Node / przejście na izolację przez task runners.

Kontekst / historia / powiązania

n8n ma wbudowane mechanizmy uruchamiania kodu użytkownika w węźle „Code”, w tym wsparcie dla Pythona. W przypadku CVE-2025-68668 problem dotyczy modelu izolacji (sandboxu) w ścieżce wykonania Pythona opartej o Pyodide.

Warto odnotować, że to nie pierwszy krytyczny temat wokół RCE w n8n w ostatnich tygodniach — The Hacker News wskazuje, że wcześniej załatano także inną krytyczną podatność RCE (CVE-2025-68613). To sygnał, że komponenty odpowiedzialne za „uruchamianie logiki użytkownika” w automatyzacji workflow są szczególnie wrażliwe i wymagają konserwatywnej konfiguracji uprawnień.

Analiza techniczna / szczegóły luki

Opis z perspektywy bezpieczeństwa aplikacji: CVE-2025-68668 jest klasyfikowane jako CWE-693 (Protection Mechanism Failure) — czyli mechanizm ochronny (sandbox) nie zapewnia oczekiwanej separacji.

Powierzchnia ataku (wg CVSS v3.1):

  • AV:N (zdalnie przez sieć), AC:L (niska złożoność),
  • PR:L (wymagane niskie uprawnienia — ale jednak jakieś),
  • UI:N (brak interakcji użytkownika),
  • S:C (scope changed — potencjalne przejście z kontekstu aplikacji do hosta),
  • wpływ: wysoki na poufność i integralność; w zależności od źródła oceny także dostępność.

Sedno problemu: jeżeli użytkownik może umieścić/uruchomić kod Pythona w Python Code Node, to w warunkach podatności jest w stanie „wyjść z sandboxu” i doprowadzić do uruchomienia poleceń systemowych na hoście, z uprawnieniami procesu n8n.

Praktyczne konsekwencje / ryzyko

Skuteczna eksploatacja może oznaczać w praktyce:

  • przejęcie instancji n8n (w zakresie uprawnień procesu n8n),
  • dostęp do danych i sekretów przetwarzanych w workflow (tokeny API, dane biznesowe),
  • modyfikację workflow (trwałe backdoory w automatyzacjach),
  • potencjalnie ruch lateralny (np. jeśli n8n ma dostęp sieciowy do innych systemów).

Ryzyko rośnie szczególnie w środowiskach, gdzie:

  • wielu użytkowników ma możliwość tworzenia/edycji workflow,
  • n8n działa w jednej sieci z systemami wrażliwymi,
  • proces n8n ma nadmiarowe uprawnienia lub szeroki egress. (To już wnioski operacyjne — warto je zweryfikować w swoim threat modelu).

Rekomendacje operacyjne / co zrobić teraz

Poniżej praktyczna lista działań „od razu” — od najlepszej opcji do doraźnych mitigacji.

A. Najlepsza opcja: aktualizacja

  1. Zaktualizuj n8n do 2.0.0 (to wersja z poprawką).

B. Doraźne obejścia, jeśli nie możesz aktualizować natychmiast

1) Wyłącz Code Node (najbardziej „twarde” ograniczenie funkcjonalności):
Zablokuj węzeł Code przez NODES_EXCLUDE. Przykład z dokumentacji pokazuje, że NODES_EXCLUDE przyjmuje tablicę nazw węzłów do zablokowania.

# przykład – zablokuj Code node (nazwa z advisora)
NODES_EXCLUDE='["n8n-nodes-base.code"]'

2) Wyłącz uruchamianie Pythona w Code node:
Advisory rekomenduje ustawienie N8N_PYTHON_ENABLED=false. 

N8N_PYTHON_ENABLED=false

3) Przejdź na izolację opartą o task runners (wspierane od 1.111.0):
n8n opisuje task runners jako mechanizm uruchamiania kodu JS/Python w sposób bardziej izolowany; dokumentacja pokazuje m.in. N8N_RUNNERS_ENABLED=true oraz N8N_NATIVE_PYTHON_RUNNER=true, a w trybie produkcyjnym preferuje się „external mode” z osobnym kontenerem/sidecarem n8nio/runners. 

# minimum wg advisora (koncepcyjnie)
N8N_RUNNERS_ENABLED=true
N8N_NATIVE_PYTHON_RUNNER=true

Uwaga operacyjna: jeśli wdrażasz external mode, dopilnuj zgodności wersji n8nio/n8n i n8nio/runners oraz ustawienia tokena autoryzacji do połączeń runnerów.

C. Dodatkowe twardnienie (uzupełniająco)

  • Ogranicz uprawnienia „create/modify workflow” tylko do w pełni zaufanych ról (szczególnie w środowiskach shared).
  • Uruchamiaj n8n w izolacji (kontener/VM), jako nie-root, z ograniczonym dostępem do filesystemu i sieci.
  • Monitoruj nietypowe wykonania Code node / zmiany workflow (alerty na modyfikacje krytycznych przepływów).

Różnice / porównania z innymi przypadkami (jeśli dotyczy)

CVE-2025-68668 dotyczy „ucieczki z sandboxu” w Python Code Node opartym o Pyodide i kończy się możliwością wykonania komend na hoście przez użytkownika z uprawnieniami do edycji workflow.

Dla porównania, nagłośniona wcześniej krytyczna podatność CVE-2025-68613 (wspomniana przez THN) była związana z inną częścią systemu (mechanizmem ewaluacji wyrażeń w workflow). Wspólny mianownik to „execution context” kontrolowany przez użytkownika — i dlatego praktyczna strategia obrony powinna obejmować zarówno aktualizacje, jak i redukcję uprawnień edycyjnych oraz izolację runtime.

Podsumowanie / kluczowe wnioski

  • CVE-2025-68668 to krytyczny sandbox bypass w n8n (Python Code Node / Pyodide), z realnym ryzykiem przejęcia hosta w kontekście uprawnień procesu n8n.
  • Luka dotyczy wersji 1.0.0–<2.0.0 i wymaga użytkownika, który może edytować workflow — ale to nadal typowy model zagrożeń w firmach i zespołach.
  • Najlepsze działanie: upgrade do 2.0.0. Jeśli nie możesz: wyłącz Code node / Python w Code node albo przejdź na task runners dla lepszej izolacji.

Źródła / bibliografia

  1. The Hacker News – opis CVE-2025-68668 i kontekst wydania 2.0.0 (The Hacker News)
  2. NVD (NIST) – karta CVE-2025-68668, wektory CVSS, opis i workaroundy (NVD)
  3. GitHub Security Advisory (n8n-io/n8n) – GHSA-62r4-hw23-cc8v, impact, patche i obejścia (GitHub)
  4. n8n Docs – Task runners (konfiguracja i external mode) (n8n Docs)
  5. n8n Docs – Block access to nodes (NODES_EXCLUDE) (n8n Docs)