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
W ekosystemie automatyzacji workflow coraz częściej spotyka się narzędzia, które łączą systemy biznesowe, API i dane „w tle”. n8n to jedna z popularniejszych platform tego typu (open source, dystrybucja m.in. przez npm), często wdrażana self-hosted. Właśnie w tym obszarze ujawniono krytyczną podatność: CVE-2025-68613 z oceną CVSS 9.9, która może umożliwić zdalne wykonanie kodu (RCE) w kontekście procesu n8n, a w praktyce – przejęcie instancji.
Kluczowy detal: exploit wymaga uwierzytelnienia, ale nie musi wymagać uprawnień administracyjnych – wystarczający może być dostęp do tworzenia/edycji workflow, co w wielu organizacjach bywa delegowane szerzej, niż powinno.
W skrócie
- CVE: CVE-2025-68613, CVSS 9.9 (Critical).
- Typ: RCE poprzez expression injection w mechanizmie ewaluacji wyrażeń używanych podczas konfiguracji workflow.
- Wymagania ataku: uwierzytelniony użytkownik; w praktyce wystarcza możliwość konfiguracji workflow.
- Wpływ: wykonanie dowolnego kodu z uprawnieniami procesu n8n → potencjalnie pełna kompromitacja instancji i danych.
- Wersje podatne: >= 0.211.0 oraz < 1.120.4 / 1.121.1 / 1.122.0.
- Poprawki: 1.120.4, 1.121.1, 1.122.0 (rekomendacja: aktualizacja do 1.122.0+).
- Skala ekspozycji: Censys raportował ~103 476 potencjalnie podatnych instancji (stan na 22 grudnia 2025).
- Status eksploatacji: Censys wskazywał „brak znanej eksploatacji” na moment publikacji, ale odnotował dostępność PoC.
Kontekst / historia / powiązania
To zdarzenie dobrze wpisuje się w szerszy trend: narzędzia automatyzacji są atrakcyjnym celem, bo zwykle mają dostęp do wielu integracji (tokeny API, webhooki, bazy, systemy plików, czasem konta chmurowe). W efekcie pojedynczy błąd typu RCE może dać atakującemu „hub” do dalszego ruchu bocznego.
W tym przypadku dodatkowym „wzmacniaczem” ryzyka jest ekspozycja publiczna: według Censys liczba potencjalnie podatnych instancji była liczona w dziesiątkach tysięcy.
Analiza techniczna / szczegóły luki
Na czym polega problem
Rdzeń podatności dotyczy sposobu, w jaki n8n ocenia (eval) wyrażenia używane przy konfiguracji workflow. W określonych warunkach wyrażenia dostarczone przez uwierzytelnionego użytkownika mogą zostać uruchomione w kontekście, który nie jest wystarczająco odizolowany od środowiska wykonawczego. To otwiera drogę do wykonania dowolnego kodu.
Orca Security opisuje to jako scenariusz „escape” z niewystarczającego sandboxa w mechanizmie ewaluacji wyrażeń, prowadzący do możliwości wykonywania komend na poziomie systemu operacyjnego z uprawnieniami procesu n8n.
Wymagane uprawnienia i wektor ataku
Zgodnie z advisory n8n, atak jest authenticated i w praktyce opiera się o możliwość dostarczenia złośliwego wyrażenia podczas tworzenia/edycji elementów workflow.
W GitHub Security Advisory podatność jest skategoryzowana jako CWE-913 (Improper Control of Dynamically-Managed Code Resources), co jest spójne z klasą błędów, gdzie dane użytkownika wpływają na dynamicznie zarządzany kod/obiekty i finalnie na wykonanie instrukcji.
Wersje podatne i naprawione
- Podatne: wersje >= 0.211.0 aż do momentu wydania poprawek.
- Naprawione: 1.120.4, 1.121.1, 1.122.0 (w praktyce: aktualizuj do gałęzi, którą utrzymujesz, a jeśli możesz – do 1.122.0+).
Praktyczne konsekwencje / ryzyko
Jeżeli atakujący zdobędzie konto (lub już je ma) z możliwością konfiguracji workflow, skutki mogą obejmować:
- pełne przejęcie instancji i wykonywanie kodu z uprawnieniami procesu n8n,
- kradzież sekretów (tokeny API, hasła w konektorach, dane uwierzytelniające do integracji),
- modyfikację workflow (trwała furtka: nowe webhooki, dodatkowe kroki „eksfiltracyjne”),
- ruch boczny w sieci (pivot do usług, do których n8n ma zaufany dostęp).
Istotna jest też skala: Censys raportował 103 476 potencjalnie podatnych instancji oraz gotowe zapytania do identyfikacji hostów, co sugeruje, że również aktorzy ofensywni mogą szybko typować cele.
Rekomendacje operacyjne / co zrobić teraz
1) Aktualizacja (priorytet P0)
- Zaktualizuj do 1.120.4 / 1.121.1 / 1.122.0 (najbezpieczniej: 1.122.0+, jeśli kompatybilność pozwala).
2) Ogranicz uprawnienia do edycji workflow (P0/P1)
Jeśli nie możesz od razu zaktualizować:
- ogranicz możliwość tworzenia i edycji workflow wyłącznie do w pełni zaufanych kont/użytkowników.
3) Twarde izolowanie procesu n8n (P1)
- uruchamiaj n8n w utwardzonym środowisku: minimalne uprawnienia systemowe, segmentacja sieci, ograniczenie egress, restrykcyjne ACL do zasobów (DB, storage, CI/CD, serwery integracyjne).
4) Szybki threat hunting / detekcja (P1)
- przejrzyj historię zmian workflow (kto i kiedy edytował),
- zweryfikuj nietypowe nowe integracje, webhooki, połączenia wychodzące,
- sprawdź logi pod kątem anomalii w czasie konfiguracji workflow (nagłe zmiany, „testowe” workflow, nowe konta).
(Źródła opisują wektor i skutki, ale nie publikują tu jednego „uniwersalnego” IOC; dlatego kluczowa jest analiza zmian i behawioru.)
5) Zarządzane środowiska
Jeśli korzystasz z hostingu/managed, potraktuj to jako check-listę: potwierdź, że dostawca wdrożył wersje naprawione i że Twoje role/uprawnienia w UI nie są nadmiarowe (szczególnie „edytorzy” workflow).
Różnice / porównania z innymi przypadkami (jeśli dotyczy)
Ten incydent jest dobrym przykładem, że „authenticated” nie znaczy „mało groźne”. W praktyce:
- narzędzia automatyzacji często mają wielu użytkowników i współdzielone workflow,
- konta użytkowników są częstym celem (phishing, password reuse),
- a sama platforma bywa wystawiona do Internetu (co potwierdza skala obserwowana przez Censys).
W odróżnieniu od klasycznych błędów typu „unauth RCE”, bariera wejścia jest wyższa, ale impact pozostaje krytyczny – bo proces n8n zwykle stoi „blisko” danych i integracji.
Podsumowanie / kluczowe wnioski
- CVE-2025-68613 (CVSS 9.9) to krytyczna podatność RCE wynikająca z niewystarczającej izolacji ewaluacji wyrażeń w n8n.
- Atak wymaga uwierzytelnienia, ale może nie wymagać administracji – co podnosi ryzyko w środowiskach z szeroką delegacją edycji workflow.
- Poprawki są dostępne (1.120.4 / 1.121.1 / 1.122.0) i należy je traktować jako pilne (P0).
- Skala potencjalnej ekspozycji liczona była w ~103 tys. instancji (Censys), więc temat ma realną „powierzchnię rażenia” w Internecie.
Źródła / bibliografia
- GitHub Security Advisory (n8n-io/n8n) – GHSA-v98v-ff95-f3cp / CVE-2025-68613 (GitHub)
- National Vulnerability Database (NVD) – CVE-2025-68613 (NVD)
- Censys Advisory – „Critical n8n Vulnerability Allows Remote Code Execution” (22 grudnia 2025) (Censys)
- The Hacker News – „Critical n8n Flaw (CVSS 9.9)…” (23 grudnia 2025) (The Hacker News)
- Orca Security – analiza ryzyka i mechanizmu RCE (Orca Security)