Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Platformy automatyzacji workflow, takie jak n8n, przetwarzają logikę biznesową, integracje z usługami zewnętrznymi oraz wrażliwe dane uwierzytelniające. Z tego powodu bezpieczeństwo mechanizmów wykonywania wyrażeń, izolacji zadań i sandboxingu ma kluczowe znaczenie dla całego środowiska. Najnowsze poprawki dla n8n eliminują zestaw krytycznych podatności, które mogą prowadzić do zdalnego wykonania kodu na hoście aplikacji, a następnie do ujawnienia lub odszyfrowania przechowywanych poświadczeń.
Problem dotyczy zarówno wdrożeń self-hosted, jak i środowisk chmurowych, a jego znaczenie wykracza poza samą aplikację. W praktyce kompromitacja n8n może oznaczać dostęp do wielu połączonych systemów, usług SaaS, baz danych i platform chmurowych.
W skrócie
W n8n ujawniono kilka krytycznych podatności, z których najważniejsze to CVE-2026-27577 oraz CVE-2026-27493. Pierwsza umożliwia ucieczkę z sandboxa mechanizmu expressions i wykonanie poleceń systemowych przez uwierzytelnionego użytkownika mającego możliwość tworzenia lub modyfikowania workflow. Druga dotyczy podwójnej ewaluacji wyrażeń w węzłach formularzy i może zostać wykorzystana bez uwierzytelnienia, jeśli publiczny formularz spełnia określone warunki konfiguracyjne.
W najbardziej niebezpiecznym scenariuszu obie luki można połączyć, uzyskując pełne RCE na serwerze n8n oraz możliwość przejęcia zapisanych sekretów. Producent wskazał, że poprawki trafiły do wersji 2.10.1, 2.9.3 oraz 1.123.22, a starsze wydania w odpowiednich gałęziach pozostają podatne.
Kontekst / historia
n8n jest szeroko wykorzystywaną platformą do budowy automatyzacji, integracji usług i orkiestracji procesów biznesowych. Ze względu na dostęp do tokenów API, kluczy dostępowych, poświadczeń OAuth i danych aplikacyjnych stanowi atrakcyjny cel dla atakujących. Naruszenie bezpieczeństwa takiej platformy ma zwykle charakter wielowarstwowy, ponieważ atakujący nie przejmuje wyłącznie jednego systemu, ale potencjalnie cały łańcuch połączonych usług.
Opisane luki zostały zgłoszone i załatane w marcu 2026 roku. W tym samym cyklu aktualizacji usunięto również inne krytyczne błędy związane z wykonywaniem kodu poza założonymi granicami izolacji. Pokazuje to, że powierzchnia ataku w nowoczesnych platformach automatyzacji obejmuje parsery wyrażeń, środowiska uruchomieniowe zadań oraz wyspecjalizowane węzły logiczne.
Analiza techniczna
Najpoważniejsza luka, CVE-2026-27577, wynikała z błędu w kompilatorze expressions. Problem dotyczył niepełnej transformacji drzewa AST podczas przepisywania wyrażeń do postaci uznawanej za bezpieczną dla sandboxa. W praktyce umożliwiało to obejście założeń izolacji i uzyskanie dostępu do mechanizmów systemowych hosta, co otwierało drogę do wykonania poleceń na serwerze.
Druga istotna podatność, CVE-2026-27493, dotyczyła węzłów formularzy. Publiczne endpointy formularzy w n8n są z założenia dostępne bez uwierzytelnienia, co jest cechą funkcjonalną produktu. Błąd polegał jednak na podwójnej ewaluacji danych wejściowych jako expressions, co umożliwiało expression injection. Odpowiednio przygotowany payload przesłany w formularzu mógł doprowadzić do wykonania nieautoryzowanej logiki.
Najgroźniejszy scenariusz powstaje przy połączeniu obu podatności. Nieuwierzytelnione wstrzyknięcie expression przez publiczny formularz może zostać zestawione z ucieczką z sandboxa, co prowadzi do zdalnego wykonania kodu na serwerze. Po uzyskaniu takiego dostępu atakujący może odczytać zmienną środowiskową N8N_ENCRYPTION_KEY i wykorzystać ją do odszyfrowania poświadczeń zapisanych w bazie danych n8n.
W tym samym zestawie poprawek usunięto również CVE-2026-27495 oraz CVE-2026-27497. Jedna z tych luk dotyczyła code injection w sandboxie JavaScript Task Runner, a druga nadużycia trybu zapytań SQL w węźle Merge w sposób pozwalający na wykonanie kodu i zapis arbitralnych plików na serwerze. To dodatkowo podkreśla, że zabezpieczanie środowisk automatyzacji wymaga ochrony wielu warstw jednocześnie.
Konsekwencje / ryzyko
Ryzyko operacyjne związane z tymi podatnościami jest bardzo wysokie. n8n często pełni rolę centralnego punktu integracyjnego, dlatego jego kompromitacja może szybko rozszerzyć się na kolejne systemy i konta usługowe.
- przejęcie serwera aplikacyjnego i wykonanie dowolnych poleceń systemowych,
- kradzież lub odszyfrowanie zapisanych sekretów i poświadczeń,
- ruch lateralny do usług chmurowych, baz danych i systemów wewnętrznych,
- modyfikacja workflow w celu utrzymania trwałego dostępu,
- sabotaż procesów biznesowych oraz automatyzacji,
- eksfiltracja danych z podłączonych platform SaaS.
Szczególnie niebezpieczne są wdrożenia, w których aktywne są formularze publiczne, a jednocześnie użytkownicy o niższym poziomie zaufania mają możliwość edytowania workflow. W takich konfiguracjach bariera dla skutecznego ataku istotnie maleje.
Rekomendacje
Najważniejszym działaniem jest niezwłoczna aktualizacja n8n do wersji 2.10.1, 2.9.3 lub 1.123.22 albo nowszej, zależnie od używanej gałęzi produktu. W praktyce łatanie powinno zostać potraktowane jako działanie priorytetowe.
- ograniczyć tworzenie i modyfikowanie workflow wyłącznie do w pełni zaufanych administratorów i operatorów,
- przeprowadzić przegląd wszystkich publicznych formularzy oraz węzłów Form i Form Trigger,
- tymczasowo wyłączyć podatne węzły przy użyciu zmiennej NODES_EXCLUDE, jeśli natychmiastowa aktualizacja nie jest możliwa,
- uruchamiać n8n w utwardzonym środowisku z minimalnymi uprawnieniami systemowymi i ograniczonym dostępem sieciowym,
- rozważyć użycie trybu external runner dla zadań wykonawczych w celu ograniczenia skutków przełamania izolacji,
- rotować wszystkie sekrety przechowywane w n8n po wykryciu oznak kompromitacji lub po dłuższym okresie ekspozycji,
- przeanalizować logi aplikacyjne, historię zmian workflow i anomalie w ruchu do formularzy,
- segmentować środowisko tak, aby host n8n nie miał zbędnego dostępu do krytycznych zasobów wewnętrznych.
Z perspektywy detekcji warto monitorować nietypowe modyfikacje workflow, wzrost liczby wywołań publicznych formularzy, anomalie w procesach potomnych systemu oraz odczyty wrażliwych zmiennych środowiskowych. Należy także sprawdzić, czy z platformy nie były wykonywane niespodziewane połączenia do zewnętrznych usług z użyciem przechowywanych tokenów.
Podsumowanie
Przypadek n8n pokazuje, że platformy automatyzacji stanowią infrastrukturę o wysokiej wartości dla atakujących, ponieważ łączą logikę biznesową z dostępem do licznych sekretów i integracji. Krytyczne błędy w expressions, formularzach i mechanizmach uruchamiania kodu mogą bardzo szybko przełożyć się na pełne przejęcie środowiska.
Organizacje korzystające z n8n powinny potraktować marcowe poprawki z 2026 roku jako pilne i równolegle wdrożyć zasadę najmniejszych uprawnień, utwardzenie hosta, segmentację sieci oraz przegląd wszystkich publicznie dostępnych workflow.