Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
W platformie n8n ujawniono podatność CVE-2026-59208, która dotyczy mechanizmu token exchange dostępnego w środowiskach enterprise. Błąd wynika z nieprawidłowego mapowania tożsamości użytkownika na podstawie tokenów JWT pochodzących od więcej niż jednego zaufanego wystawcy.
W praktyce oznacza to, że system mógł rozpoznawać użytkownika wyłącznie na podstawie pola sub, pomijając jednocześnie pole iss. Taki model otwiera drogę do nieautoryzowanego zalogowania się na konto innego użytkownika, jeśli dwa różne systemy tożsamości wygenerują tokeny z identyczną wartością identyfikatora podmiotu.
W skrócie
- Podatność dotyczy n8n z aktywną funkcją token exchange i konfiguracją więcej niż jednego zaufanego issueru.
- Źródłem problemu jest mapowanie tożsamości wyłącznie po
sub, bez uwzględnieniaiss. - Skutkiem może być przejęcie konta między odrębnymi domenami tożsamości.
- Poprawki udostępniono w wersjach 2.27.4 oraz 2.28.1.
- Za podatne należy uznać wersje wcześniejsze niż 2.27.4 oraz wydanie 2.28.0.
Kontekst / historia
n8n to platforma do automatyzacji workflow, szeroko stosowana zarówno we wdrożeniach własnych, jak i w modelach embedded oraz OEM. W takich scenariuszach token exchange upraszcza proces logowania użytkowników końcowych przez akceptowanie zewnętrznie wystawionych tokenów JWT.
Opisana luka została ujawniona jako GHSA-mq3m-f8x3-579w i otrzymała identyfikator CVE-2026-59208. Publicznie wskazano, że poprawka została opublikowana 24 czerwca 2026 roku, natomiast wpis CVE pojawił się publicznie 9 lipca 2026 roku. Problem nie dotyczy wszystkich instalacji, lecz wyłącznie tych, w których token exchange jest aktywny i jednocześnie skonfigurowano więcej niż jednego zaufanego wystawcę.
Analiza techniczna
Rdzeniem podatności jest logiczny błąd wiązania zewnętrznej tożsamości z lokalnym kontem użytkownika w n8n. W środowiskach wieloissuerowych sama wartość sub nie powinna być traktowana jako globalnie unikalna, ponieważ może się powtarzać pomiędzy różnymi dostawcami tożsamości.
W podatnym wariancie aplikacja rozwiązywała tożsamość użytkownika wyłącznie na podstawie sub. Jeśli więc zaufany issuer A wystawił token z takim samym sub jak użytkownik powiązany z issuerem B, system mógł przypisać sesję do niewłaściwego konta lokalnego. W efekcie atakujący dysponujący ważnym tokenem od jednego z zaufanych issuerów mógł, przy kolizji identyfikatora, zalogować się jako inny użytkownik.
To nie jest błąd kryptograficzny JWT, lecz klasyczna wada logiczna związana z federacją tożsamości i błędnym modelem autoryzacji. W poprawnym podejściu para iss + sub powinna być traktowana jako pełny identyfikator podmiotu. Pominięcie kontekstu wystawcy narusza izolację między domenami tożsamości, mimo że podpis tokenu pozostaje prawidłowy.
Klasyfikacja błędu podkreśla jego znaczenie. Problem został powiązany z kategoriami CWE-287 oraz CWE-346, co odzwierciedla jednocześnie niewłaściwe uwierzytelnienie i błędną walidację pochodzenia tożsamości.
Konsekwencje / ryzyko
Najpoważniejszym skutkiem luki jest możliwość przejęcia konta bez znajomości hasła ofiary. Wystarczy, że atakujący uzyska ważny token od jednego z zaufanych issuerów, a następnie wykorzysta sytuację, w której wartość sub koliduje z użytkownikiem pochodzącym od innego issueru.
Wpływ incydentu zależy od uprawnień przejętego konta. W środowiskach n8n może to oznaczać dostęp do krytycznych elementów operacyjnych i danych.
- definicji i konfiguracji workflow,
- danych przesyłanych pomiędzy integracjami,
- poświadczeń do usług zewnętrznych,
- historii wykonania procesów,
- funkcji administracyjnych i operacyjnych.
W praktyce przekłada się to na ryzyko wycieku danych, manipulacji logiką automatyzacji, sabotażu procesów biznesowych oraz potencjalnego ruchu bocznego do innych systemów powiązanych z platformą. Szczególnie narażone są organizacje korzystające z federacji wielu źródeł tożsamości w środowiskach enterprise i OEM.
Rekomendacje
Priorytetem powinno być jak najszybsze zaktualizowanie n8n do wersji 2.27.4, 2.28.1 lub nowszej, zależnie od używanej gałęzi wdrożeniowej. Wszystkie wersje wcześniejsze niż 2.27.4 oraz wydanie 2.28.0 należy uznać za podatne.
Jeżeli natychmiastowa aktualizacja nie jest możliwa, warto ograniczyć ekspozycję poprzez działania tymczasowe.
- zredukować konfigurację do jednego zaufanego issueru, jeśli architektura na to pozwala,
- wyłączyć funkcję token exchange, jeśli nie jest aktywnie wykorzystywana,
- przeanalizować zasady mapowania użytkowników i relacje zaufania,
- zweryfikować logi pod kątem nietypowych logowań oraz kolizji identyfikatorów,
- ograniczyć uprawnienia kont korzystających z federacji tożsamości.
W dłuższej perspektywie organizacje powinny traktować iss i sub jako nierozdzielny identyfikator użytkownika, regularnie testować scenariusze kolizji między issuerami oraz audytować mechanizmy SSO, embedded login i trust relationships. Równie ważne jest monitorowanie advisory bezpieczeństwa producenta, a nie tylko standardowych changelogów.
Podsumowanie
CVE-2026-59208 pokazuje, że nawet poprawnie podpisane tokeny JWT nie gwarantują bezpieczeństwa, jeśli aplikacja błędnie interpretuje semantykę tożsamości. W przypadku n8n problemem nie był sam mechanizm token exchange, lecz nieuwzględnienie kontekstu wystawcy podczas mapowania użytkownika.
Dla administratorów i zespołów bezpieczeństwa to ważne przypomnienie, że wdrożenia federacji tożsamości wymagają równie rygorystycznego audytu jak klasyczne systemy uwierzytelniania. W środowiskach korzystających z wielu zaufanych issuerów z pozoru drobna wada logiczna może prowadzić do pełnego przejęcia konta.
Źródła
- Cross-Issuer Token Exchange Account Binding via Subject-Only Identity Resolution — https://github.com/n8n-io/n8n/security/advisories/GHSA-mq3m-f8x3-579w
- NVD – CVE-2026-59208 — https://nvd.nist.gov/vuln/detail/CVE-2026-59208
- n8n Token Exchange Flaw Could Let Attackers Log In as Users From Another Issuer — https://thehackernews.com/2026/07/n8n-token-exchange-flaw-could-let.html