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 również jako „AI workflow automation”), w której użytkownicy konfigurują przepływy danych, integracje i logikę (m.in. poprzez wyrażenia JavaScript w parametrach węzłów). Ta elastyczność jest jednocześnie największym ryzykiem: jeżeli mechanizm „sandboxowania” i sanityzacji wyrażeń jest niekompletny, użytkownik z uprawnieniami do tworzenia/edycji workflow może doprowadzić do wyjścia z sandboxa (sandbox escape) i uruchomienia kodu na hoście.
Właśnie to dotyczy CVE-2026-25049 – krytycznej podatności prowadzącej do zdalnego wykonania kodu (RCE), dla której opisano publiczne PoC/exploity.
W skrócie
- CVE-2026-25049: krytyczna podatność n8n umożliwiająca RCE poprzez obejście mechanizmu sanityzacji/sandboxa wyrażeń używanych w workflow.
- Wektor ataku: typowo wymaga konta z możliwością tworzenia lub edycji workflow (PR:L), ale skutki to pełne przejęcie instancji/serwera.
- Skutki: kradzież sekretów (API keys, OAuth), danych konfiguracyjnych, pivot do systemów wewnętrznych i kont chmurowych; w środowiskach multi-tenant potencjalne ryzyko „przeskoku” w obrębie klastra/usług wewnętrznych.
- Poprawki: zalecane aktualizacje do najnowszych wydań (w praktyce w obiegu komunikatów pojawiają się linie 1.x oraz 2.x; przykładowo wskazywane są 1.123.17 i 2.5.2 jako wersje docelowe).
Kontekst / historia / powiązania
To nie jest pierwszy raz, gdy n8n trafia na radar z krytycznymi podatnościami w krótkim oknie czasu:
- CVE-2026-25049 została opisana jako obejście wcześniejszej poprawki na inną krytyczną podatność (w doniesieniach pojawia się CVE-2025-68613), co sugeruje problem klasy „patch bypass” i trudność w domknięciu całej klasy błędów w mechanizmie izolacji wyrażeń.
- W styczniu 2026 r. n8n publikowało także advisory dotyczące podatności w określonych typach workflow (form-based), naprawionej w wersji 1.121.0 – to pokazuje, że powierzchnia ataku bywa szeroka i zależna od konfiguracji przepływów.
W praktyce: jeśli n8n jest „centralnym kręgosłupem automatyzacji” (a często jest), to skuteczny exploit nie kończy się na samym serwerze n8n — kończy się na tym, do czego n8n ma dostęp.
Analiza techniczna / szczegóły luki
1) Gdzie leży problem
Kluczowy element to sposób, w jaki n8n interpretuje i „oczyszcza” wyrażenia (Expressions) w workflow. Raporty badaczy wskazują na niekompletną izolację kontekstu wykonania oraz luki w sanityzacji, które dają się ominąć równoważnymi konstrukcjami językowymi (typowy „denylist bypass”).
2) Dlaczego to kończy się RCE
Wyrażenia, które miały być „bezpieczne”, mogą uzyskać dostęp do obiektów środowiska uruchomieniowego (np. kontekstu Node.js), co prowadzi do:
- wykonania poleceń systemowych,
- dostępu do systemu plików,
- odczytu sekretów i konfiguracji,
- uruchomienia kolejnych etapów łańcucha ataku.
3) Wersje i poprawki
W publicznych opisach podatności (rekord CVE oraz komunikaty branżowe) pojawia się zakres „przed” określonymi wersjami w liniach 1.x i 2.x (np. przed 1.123.17 i 2.5.2).
Praktyczne konsekwencje / ryzyko
Jeśli atakujący uzyska możliwość edycji workflow (np. przez:
- przejęcie konta operatora,
- błędnie skonfigurowane role,
- dostęp współdzielony w organizacji/kliencie),
to CVE-2026-25049 może pozwolić na: - Kradzież wszystkich credentiali przechowywanych w n8n (API keys, OAuth tokens, sekrety integracji).
- Ruch lateralny: pivot do systemów, z którymi n8n się łączy (bazy danych, CI/CD, chmura, SaaS).
- Sabotaż procesów i „ciche” manipulacje: podmiana logiki workflow, modyfikowanie danych, przekierowania, w kontekście AI również możliwość ingerencji w przepływy promptów/odpowiedzi.
- W środowiskach multi-tenant: ryzyko dotknięcia innych danych/tenantów poprzez dostęp do usług wewnętrznych klastra.
Warto podkreślić: „tylko uwierzytelniony użytkownik” w praktyce często oznacza każdy, kto dostanie najniższe uprawnienia edycyjne w narzędziu automatyzacji — a to bywa łatwiejsze niż klasyczny RCE z internetu.
Rekomendacje operacyjne / co zrobić teraz
- Aktualizacja n8n natychmiast
- Zaktualizuj do wersji naprawiających CVE-2026-25049 wskazywanych w komunikatach (w obiegu: np. 1.123.17 i 2.5.2 jako bezpieczne punkty dla odpowiednich linii).
- Ogranicz uprawnienia do tworzenia/edycji workflow
- Traktuj workflow-edit jako uprawnienie uprzywilejowane (admin-like).
- Zastosuj zasadę najmniejszych uprawnień, osobne konta serwisowe, MFA/SSO jeśli dostępne.
- GitHub advisory wprost podaje: ograniczyć tworzenie/edycję workflow do w pełni zaufanych użytkowników jako doraźne ograniczenie ryzyka.
- Rotacja sekretów
- Po aktualizacji rozważ rotację N8N_ENCRYPTION_KEY oraz wszystkich credentiali i tokenów przechowywanych/obsługiwanych przez n8n (zwłaszcza chmura/CI/CD). To zalecenie pojawia się w rekomendacjach operacyjnych po publikacji podatności.
- Przegląd workflow pod kątem wskaźników nadużyć
- Szukaj podejrzanych wyrażeń w parametrach węzłów, nieoczekiwanych zmian, nowych workflow, nietypowych integracji/endpointów.
- Zweryfikuj logi uruchomień workflow oraz zmiany konfiguracji.
- Hardening środowiska uruchomieniowego
- Uruchamiaj n8n w środowisku o ograniczonych uprawnieniach OS (non-root), z restrykcyjnym AppArmor/SELinux (gdzie możliwe), ograniczeniami syscalls/kapabilitami.
- Segmentacja sieci + ograniczenie egress: n8n nie powinien „móc wszędzie”.
- GitHub advisory podkreśla, że hardening i ograniczenia sieciowe zmniejszają wpływ ewentualnej eksploatacji, choć nie usuwają przyczyny.
Różnice / porównania z innymi przypadkami (jeśli dotyczy)
- CVE-2026-25049 to klasyczny przypadek „sandbox escape → RCE” w mechanizmie interpretacji logiki użytkownika (Expressions). Gdy bezpieczeństwo opiera się o sanityzację/denylisty, często kończy się to obejściami, bo język (JS) ma wiele równoważnych konstrukcji.
- W przeciwieństwie do podatności zależnych od specyficznych typów workflow (np. form-based scenariusze w advisory n8n), tutaj ryzyko jest „bardziej systemowe”: dotyka samego mechanizmu wyrażeń używanego bardzo szeroko w automatyzacjach.
Podsumowanie / kluczowe wnioski
- CVE-2026-25049 to krytyczna podatność n8n umożliwiająca przejęcie serwera poprzez mechanizm wyrażeń w workflow — a PoC/exploity są publicznie opisywane.
- Realne ryzyko jest szczególnie wysokie tam, gdzie n8n ma szerokie integracje i dostęp do sekretów: udany atak często oznacza przejęcie całego łańcucha automatyzacji.
- Najważniejsze działania: patch now, ograniczenie uprawnień edycyjnych workflow, rotacja sekretów i hardening środowiska.
Źródła / bibliografia
- BleepingComputer — „Critical n8n flaws disclosed along with public exploits” (BleepingComputer)
- GitHub Advisory Database — GHSA-6cqr-8cfr-67f8 / CVE-2026-25049 (GitHub)
- Pillar Security — opis podatności „sandbox escape” w n8n (pillar.security)
- Endor Labs — analiza i kontekst obejścia sanityzacji (CVE-2026-25049) (endorlabs.com)
- Oficjalny rekord CVE (cve.org) — CVE-2026-25049 (cve.org)