Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Ujawnienie tokenów API n8n w publicznych commitach może prowadzić do bezpośredniego, nieautoryzowanego dostępu do środowisk automatyzacji. Nie chodzi tu o klasyczną podatność typu CVE, lecz o krytyczny problem zarządzania sekretami: ważne klucze uwierzytelniające trafiają do publicznych repozytoriów i pozostają aktywne na dostępnych z internetu instancjach.
W praktyce oznacza to możliwość uzyskania dostępu do workflowów, historii wykonań, danych tabelarycznych, zmiennych konfiguracyjnych oraz poświadczeń wykorzystywanych do komunikacji z innymi usługami. Dla organizacji korzystających z n8n taki incydent może oznaczać naruszenie nie tylko samej platformy, ale również całego ekosystemu integracji.
W skrócie
Badacze bezpieczeństwa zidentyfikowali tysiące tokenów API n8n opublikowanych w publicznych commitach i powiązali je z dużą liczbą hostów. W części przypadków publicznie dostępne instancje nadal akceptowały co najmniej jeden ujawniony token, co otwierało drogę do autoryzowanego, ale nieuprawnionego dostępu.
- wyciek dotyczył tokenów API publikowanych razem z informacjami o instancjach,
- atak nie wymagał wykorzystania exploita ani luki w kodzie,
- ważny token mógł umożliwić odczyt konfiguracji i danych,
- w określonych scenariuszach możliwe było także nadużycie zapisanych poświadczeń.
Kontekst / historia
n8n to popularna platforma open source do automatyzacji workflowów, szeroko wykorzystywana do integracji systemów biznesowych, usług chmurowych, baz danych, narzędzi deweloperskich oraz aplikacji opartych na AI. Z perspektywy bezpieczeństwa to zasób o wysokiej wartości, ponieważ centralizuje procesy i przechowuje dostęp do wielu usług zależnych.
W opisywanych przypadkach źródłem problemu były przede wszystkim pliki środowiskowe, konfiguracje narzędzi deweloperskich i komendy API pozostawione w historii commitów. Jeśli wraz z tokenem publicznie ujawniono także adres instancji, napastnik nie musiał prowadzić rozbudowanego rozpoznania. Otrzymywał gotowy zestaw danych potrzebnych do wykonania żądań uwierzytelnionych.
Znaczenie miał również model życia tokenów. Starsze klucze mogły funkcjonować bez daty wygaśnięcia, co zwiększało ryzyko, że sekret opublikowany wiele miesięcy wcześniej nadal pozostaje aktywny. Tego typu sytuacja znacząco wydłuża okno ataku i utrudnia ocenę skali ekspozycji.
Analiza techniczna
Mechanizm nadużycia był stosunkowo prosty. Znając adres instancji i posiadając ważny token API, atakujący mógł wykonywać uwierzytelnione żądania do interfejsu n8n. Już podstawowy dostęp odczytowy pozwalał na zebranie informacji o użytkownikach, workflowach, historii wykonań, tabelach danych oraz zmiennych środowiskowych dostępnych z poziomu platformy.
Szczególnie cenne dla napastnika są definicje workflowów. Mogą one zawierać logikę biznesową, kod wykonywany w node’ach, zapytania do baz danych, parametry połączeń, a czasem również sekrety wpisane bezpośrednio w konfiguracji. Nawet jeśli interfejs nie zwraca jawnie wartości wszystkich poświadczeń, sam dostęp do obiektów credential może umożliwić ich praktyczne wykorzystanie w nowych lub zmodyfikowanych workflowach.
Opisywane scenariusze obejmowały kilka etapów: enumerację instancji i użytkowników, odczyt workflowów, nadużycie zapisanych poświadczeń do wykonywania działań w usługach zewnętrznych, dostęp do danych przechowywanych w tabelach oraz próby doprowadzenia do ujawnienia rzeczywistych wartości sekretów poprzez odpowiednio skonfigurowane operacje wychodzące. Dodatkowym problemem pozostaje funkcja audytowa, która dla uwierzytelnionego użytkownika może prezentować stan bezpieczeństwa instancji i tym samym ułatwiać priorytetyzację dalszych działań ofensywnych.
Konsekwencje / ryzyko
Ryzyko wynikające z kompromitacji tokenów n8n wykracza daleko poza samą platformę automatyzacji. n8n bardzo często pełni rolę centralnego pośrednika między wieloma usługami, dlatego przejęcie dostępu do jednej instancji może uruchomić efekt domina w całym środowisku organizacji.
- ujawnienie danych operacyjnych i biznesowych przetwarzanych przez workflowy,
- ekspozycja danych osobowych obecnych w wykonaniach i tabelach,
- poznanie logiki integracji oraz automatyzacji wewnętrznych procesów,
- wykorzystanie zapisanych poświadczeń do działań w usługach zewnętrznych,
- możliwość dalszej kompromitacji łańcucha integracji,
- ruch boczny do innych systemów podłączonych do platformy.
W praktyce skutki takiego incydentu mogą odpowiadać częściowemu przejęciu uprzywilejowanej warstwy integracyjnej przedsiębiorstwa. To szczególnie groźne tam, gdzie n8n obsługuje procesy finansowe, CRM, systemy zgłoszeniowe, bazy danych lub narzędzia administracyjne.
Rekomendacje
Organizacje powinny traktować wyciek tokenów API n8n jak incydent związany z naruszeniem poświadczeń. Sama analiza kodu źródłowego nie wystarczy — konieczne są jednocześnie działania reakcyjne, przegląd uprawnień i wzmocnienie procesów kontroli sekretów.
- zinwentaryzować wszystkie tokeny API n8n i natychmiast unieważnić te, które mogły zostać ujawnione,
- przeprowadzić rotację poświadczeń przechowywanych w n8n, zwłaszcza jeśli mogły zostać użyte przez nieautoryzowany workflow,
- sprawdzić historię commitów, pipeline’y CI/CD i pliki konfiguracyjne pod kątem obecności kluczy oraz adresów instancji,
- wymusić czas życia tokenów i regularną rotację sekretów,
- ograniczyć uprawnienia kont tworzących tokeny zgodnie z zasadą najmniejszych uprawnień,
- monitorować logi API, tworzenie nowych workflowów i nietypowe połączenia wychodzące,
- usunąć sekrety zapisane jawnie w konfiguracji node’ów,
- ograniczyć dostęp do API i paneli administracyjnych do zaufanych sieci,
- wdrożyć skanowanie sekretów, hooki pre-commit i blokady publikacji wrażliwych plików,
- zweryfikować aktualność używanej wersji n8n i stan zabezpieczeń instancji.
Z punktu widzenia SOC oraz zespołów reagowania warto dodatkowo szukać anomalii, takich jak krótkotrwałe workflowy tworzone tylko na potrzeby testów, gwałtowny wzrost odczytów historii wykonań czy nietypowe żądania HTTP do nieznanych hostów inicjowane z poziomu platformy.
Podsumowanie
Incydent związany z wyciekami tokenów API n8n pokazuje, że kompromitacja sekretów integracyjnych może być równie niebezpieczna jak klasyczne luki w oprogramowaniu. W tym przypadku kluczowym wektorem ataku nie był exploit, lecz ważny token zapewniający uwierzytelniony dostęp do platformy o szerokich uprawnieniach.
Najważniejszy wniosek jest prosty: tokeny API platform automatyzacji należy traktować jak poświadczenia uprzywilejowane. Ich ujawnienie może doprowadzić do ekspozycji danych, nadużycia workflowów, wykorzystania kont usługowych i dalszej kompromitacji środowiska. Skuteczna obrona wymaga połączenia rotacji sekretów, ścisłej kontroli uprawnień, monitorowania aktywności API oraz ciągłego skanowania repozytoriów pod kątem wycieków.
Źródła
- The Hacker News — https://thehackernews.com/2026/08/leaked-n8n-api-tokens-exposed-live.html
- n8n Blog: Introducing the n8n public API — https://blog.n8n.io/introducing-the-n8n-public-api/
- CISA Known Exploited Vulnerabilities Catalog — https://www.cisa.gov/known-exploited-vulnerabilities-catalog?page=0