n8n CVE-2026-21858 Ni8mare: formularz, plik i krytyczny błąd bez logowania

CVE-2026-21858, nazywana przez badaczy Ni8mare, to krytyczna podatność w n8n oceniona na CVSS 10,0. Dotyczy wersji od 1.65.0 do wydań wcześniejszych niż 1.121.0 i została naprawiona w 1.121.0; linia 2.x nie była podatna. n8n Cloud został zaktualizowany przez operatora. W określonej konfiguracji publicznego formularza nieuwierzytelniony użytkownik mógł doprowadzić do odczytu lokalnych plików z serwera.

Najważniejsze jest precyzyjne opisanie warunków. Podatny scenariusz wymaga aktywnego workflow z węzłem Form Submission oraz końcowym Form Ending, który zwraca plik binarny. Nie każda instancja n8n i nie każdy webhook był automatycznie eksploatowalny. Z drugiej strony organizacje często mają dziesiątki workflow tworzonych przez różne zespoły, więc brak wiedzy o takim formularzu nie jest dowodem jego braku.

Co mówi producent, a czego nie należy nadinterpretować

Oficjalny advisory n8n mówi o niewłaściwym przetwarzaniu żądania, które może umożliwić dostęp do plików oraz — zależnie od wdrożenia i workflow — dalsze przejęcie. Nie należy automatycznie przedstawiać CVE-2026-21858 jako bezwarunkowego RCE w każdej instalacji. Odczyt pliku jest jednak poważnym prymitywem, bo serwer automatyzacji zwykle ma dostęp do konfiguracji, bazy, tokenów, kluczy i sekretów integracji.

Jeżeli napastnik odczyta plik środowiskowy, konfigurację n8n, bazę SQLite albo klucz szyfrujący credentials, może przejść od informacji do przejęcia poświadczeń. Wpływ zależy od miejsca przechowywania danych, praw procesu, rodzaju bazy i tego, czy sekrety są w zewnętrznym vault. Dlatego raport powinien rozdzielać potwierdzony prymityw odczytu od hipotetycznych etapów po nim.

Dlaczego platforma automatyzacji ma tak wysoki blast radius

n8n łączy systemy, które normalnie nie ufają sobie bezpośrednio: CRM, pocztę, chmurę, repozytoria, komunikatory, bazy i narzędzia administracyjne. Jeden workflow może posiadać credential do wielu tenantów. Proces aplikacji ma również dostęp do definicji przepływów, historii wykonań i danych przechodzących między krokami.

Publiczny endpoint formularza wygląda jak funkcja biznesowa niskiego ryzyka, lecz za nim działa silnik z uprzywilejowanymi integracjami. To klasyczny przypadek asymetrii: anonimowe wejście spotyka się z backendem posiadającym szerokie zaufanie. Segmentacja i minimalne uprawnienia credentiali decydują, czy odczyt jednego pliku stanie się incydentem obejmującym wiele systemów.

Jak ustalić ekspozycję bez eksploatacji

Najpierw zapisz wersję aplikacji, sposób instalacji i tryb utrzymania: npm, Docker, Helm, appliance, usługa hostowana. Potwierdź działający obraz lub pakiet, nie tylko tag w pliku IaC. Mutable tag może wskazywać nowy obraz w rejestrze, podczas gdy kontener nadal działa ze starym digestem.

Następnie zinwentaryzuj aktywne workflow i wyszukaj kombinację Form Submission → Form Ending zwracającą binary. Zapisz publiczny URL, uwierzytelnienie przed reverse proxy, właściciela, ostatnią zmianę i dane dostępne dla procesu. Przegląd eksportu workflow jest bezpieczniejszy niż wysyłanie path-traversal payloadów do produkcji.

Jeżeli nie można natychmiast zaktualizować, producent nie podaje pełnego workaroundu. Tymczasowo należy wyłączyć lub ograniczyć publiczne formularze i webhooki, szczególnie podatną kombinację, na poziomie aplikacji i reverse proxy. To ograniczenie ma trwać tylko do wdrożenia poprawki.

Aktualizacja i walidacja

Minimalnym poprawionym wydaniem linii 1.x jest 1.121.0. Po aktualizacji:

1. potwierdź wersję i digest na każdym workerze, mainie i instancji standby;
2. zrestartuj procesy tak, aby nowy kod rzeczywiście działał;
3. uruchom syntetyczny formularz na pliku testowym bez dostępu do systemu plików;
4. sprawdź, że próby podania ścieżki nie zwracają pliku ani szczegółowego błędu;
5. przetestuj legalne workflow, kolejki, credential store i callbacki;
6. usuń stare obrazy z automatycznego rollbacku, jeśli mogą przywrócić podatną wersję.

Nie wystarczy zaktualizować edytora przy pozostawieniu starych workerów. W architekturze queue mode ruch może być obsługiwany przez procesy o różnych wersjach.

Dochodzenie i rotacja sekretów

Przejrzyj logi reverse proxy i n8n pod kątem nietypowych parametrów, zakodowanych separatorów ścieżki, wielu błędów 4xx/5xx, odpowiedzi o rozmiarach nietypowych dla formularza i automatycznego skanowania. Zbuduj linię czasu dla wszystkich publicznych endpointów. Sprawdź historię wykonań workflow, nowe i zmienione definicje, konta, API keys i logowania administratorów.

Jeżeli istnieje wiarygodny dowód odczytu pliku, ustal co mógł przeczytać użytkownik procesu. Priorytet rotacji zwykle obejmuje N8N_ENCRYPTION_KEY, dane bazy, credentiale do chmur, repozytoriów, poczty, webhook signing secrets i tokeny OAuth. Rotacja musi objąć system źródłowy, nie tylko rekord w n8n.

W przypadku możliwego przejęcia credential store eksportuj wyłącznie zweryfikowane workflow, zbuduj czyste środowisko i ponownie powiąż sekrety. Przywrócenie całej bazy ze starego backupu może odtworzyć narażone klucze, nieautoryzowane workflow lub podatny stan.

Hardening n8n po incydencie

• uruchamiaj proces jako nie-root na systemie plików tylko do odczytu;
• montuj wyłącznie wymagane wolumeny, bez socketu Dockera i katalogów hosta;
• trzymaj sekrety w zewnętrznym managerze i nadaj każdemu credentialowi minimalny zakres;
• oddziel publiczne webhooki od panelu administracyjnego;
• stosuj egress allowlist dla workerów;
• wersjonuj i recenzuj workflow jak kod;
• loguj publikację i zmianę publicznych endpointów;
• testuj odtwarzanie z czystego obrazu.

Zestaw te działania z bezpieczeństwem API, zarządzaniem sekretami i bezpieczeństwem łańcucha dostaw. Jeśli publiczne automatyzacje mają dostęp do krytycznych systemów, BreachRoad może zweryfikować ich granice zaufania.

---

Źródła pierwotne: n8n Security Advisory, GitHub Security Advisory GHSA-v4pr-fm98-w9pg.