Krytyczna luka w n8n (CVE-2026-21858). Co teraz?

Wykryto podatność w n8n, która pozwala atakującemu bez logowania wczytać pliki z serwera, wyciągnąć sekret aplikacji oraz dane użytkowników, a finalnie „skleić” sobie sesję admina i odpalić własny kod po stronie serwera. Masakra. Jeśli stawiasz n8n samodzielnie i nie jesteś jeszcze na wersji co najmniej 1.121.0, to masz problem, który wymaga natychmiastowego działania.

O co chodzi w CVE-2026-21858? Co się dzieje?

​n8n to orkiestrator automatyzacji, który spina API, bazy, chmury i teraz także modele AI, więc z definicji przechowuje tokeny, hasła i sekrety do połowy twojej infrastruktury. W CVE-2026-21858 ktoś znalazł błąd logiki w obsłudze webhooków i formularzy, który pozwala zamieszać w sposobie parsowania requestu. Efekt jest taki, że możesz wysłać sprytnie zbudowane żądanie HTTP do endpointu formularza i zmusić n8n do sięgnięcia po dowolne pliki z lokalnego systemu plików.

Jak wygląda łańcuch ataku na n8n?

Z perspektywy napastnika scenariusz jest mega prosty. Najpierw trzeba namierzyć publicznie wystawiony endpoint n8n – zwykle formularz lub webhook, który wisi w sieci bez dodatkowego uwierzytelniania, bo „przecież to tylko foremka do zapisu na newsletter”. Potem wchodzi w grę sprytnie przygotowany request z podmienionym Content-Type i nietypową strukturą body, który przejeżdża przez wspólną ścieżkę parsowania żądania i w końcu trafia na fragment kodu, który operuje na plikach bez ponownej walidacji tego typu.

W tym momencie n8n traktuje dane wskazane w żądaniu jak referencję do pliku i pozwala atakującemu odczytać pliki z dysku. Z tych plików da się wyciągnąć m.in. informacje o użytkownikach oraz sekrety używane do podpisywania ciasteczek auth, co otwiera drogę do pełnego przejęcia konta administratora. A kiedy masz już panel admina, nie potrzebujesz kolejnego exploita – wystarczy, że zdefiniujesz workflow z node’em typu Execute Command i uruchomisz dowolny shellowy payload na serwerze.

Które instancje n8n są zagrożone?

CVE-2026-21858 dotyczy self‑hostowanych instalacji n8n, które nie zostały zaktualizowane do wersji co najmniej 1.121.0, gdzie producent już poprawił obsługę webhooków i dostępu do plików. Problem dotyczy głównie środowisk, w których formularze i webhooki wiszą otwarte na internet, bo wtedy atak nie wymaga żadnego uprzedniego dostępu ani konta. Jeżeli trzymasz n8n w prywatnej sieci, za VPN‑em albo reverse proxy z autoryzacją, ryzyko spada, ale nie znika – wewnętrzny atakujący wciąż może wykorzystać błąd, żeby przeskoczyć poziom uprawnień.

Co powinieneś zrobić teraz?

Pierwszy krok to aktualizacja – wskakujesz na wersję 1.121.0 lub nowszą zgodnie z zaleceniem twórców n8n i dopiero potem odetchniesz z ulgą. Jeżeli używasz dystrybucji z paczkami albo gotowych obrazów Docker, upewnij się, że faktycznie podnosisz tag do builda zawierającego patch, a nie tylko robisz restart kontenera na starym obrazie.

Pamiętaj: Po aktualizacji warto przejrzeć konfigurację ekspozycji n8n – najlepiej odetnij go wszędzie tam, gdzie nie musisz mieć publicznego webhooka i wrzuć dodatkową warstwę typu reverse proxy z autoryzacją do panelu jak już.

​Drugi temat to sprzątanie po możliwym incydencie. Załóż, że każde poświadczenie trzymane w n8n mogło wyciec: API keye, OAuth, dane logowania do baz i kont w chmurze – zacznij rotację tych sekretów, szczególnie tych o najwyższych uprawnieniach. Dobrze jest też zerknąć w logi wykonania workflowów i logi reverse proxy, żeby wyłapać podejrzane żądania pod formularze – nietypowe Content-Type, nietypowy rozmiar body, dziwne ścieżki czy hosty źródłowe.

Zabezpiecz n8n na przyszłość

Jeżeli używasz n8n do automatyzacji hostingu, devopsu czy ogólnie rzeczy około‑infra, potraktuj go jak krytyczny komponent, a nie kolejny dashboard. Trzymaj instancję za WAF‑em lub reverse proxy, nie wystawiaj panelu admina na goły internet i wymagaj uwierzytelniania nawet tam, gdzie formularz wydaje się „publiczny z definicji”. Ogranicz używanie node’ów, które mogą uruchamiać komendy lub skrypty po stronie serwera, do absolutnego minimum i tylko w wąsko zdefiniowanych workflowach.

Z punktu widzenia bezpieczeństwa fajnie sprawdza się prosty checklist: regularne aktualizacje n8n, rotacja sekretów, logowanie i monitoring nietypowych requestów oraz okresowy przegląd workflowów pod kątem tego, jakie uprawnienia i dane realnie potrzebują. CVE-2026-21858 pokazuje, że automatyzacja potrafi boleśnie uderzyć, kiedy ktoś z zewnątrz dostanie się do twojego „mózgu integracji”, więc lepiej traktuj tę usługę jak skrzyżowanie panelu admina z menedżerem haseł, a nie niewinną nakładkę do API.