Nach Angaben von n8n betrifft CVE-2026-59208 alle Versionen unterhalb von 2.27.4 sowie die Version 2.28.0. Korrigiert wurde das Problem erstmals in 2.27.4 und 2.28.1. Am 16. Juli führte das npm-Paket von n8n laut The Hacker News sowohl beim Kennzeichen „latest“ als auch bei „stable“ die Version 2.30.6.
Gemeldet wurde die Schwachstelle laut CVE-Eintrag vom GitHub-Konto bearsyankees. Dessen Profil verweist auf Strix, ein Unternehmen für einen KI-Agenten für Penetrationstests. Strix erklärte, der Agent habe den Token-Exchange-Ablauf untersucht und dabei den Fehler in der Identitätsbindung gefunden.
Token Exchange ist bei n8n der Enterprise-Mechanismus für OEM-Partner, die das Produkt eingebettet einsetzen. Die Funktion ist eine Umsetzung von RFC 8693 und soll einen zusätzlichen Anmeldebildschirm für Endnutzer vermeiden. Dabei signiert der Partner ein kurzlebiges JWT mit seinem eigenen Schlüssel, n8n prüft dieses gegen einen konfigurierten öffentlichen Schlüssel und ordnet die Ansprüche einem lokalen Konto zu. Vertrauenswürdige Schlüssel werden in N8N_TOKEN_EXCHANGE_TRUSTED_KEYS hinterlegt; die Bereitstellungsdokumentation kennzeichnet die Funktion weiterhin als Vorschau.
Der Kern des Problems lag in dieser Zuordnung. Wie im Quelltext unter Verweis auf RFC 7519 erläutert wird, ist ein „sub“-Wert nur im Kontext des ausstellenden Issuers eindeutig oder muss global eindeutig sein. Der maßgebliche Benutzerbezeichner ist daher die Kombination aus „iss“ und „sub“. n8n zog jedoch nur die Hälfte dieses Paars heran. Wenn zwei Issuer dieselbe Subjekt-Zeichenfolge ausgeben, konnten beide auf dasselbe n8n-Konto abgebildet werden.
n8n betont, dass keine anderen Funktionen betroffen seien. Die Angriffsfläche ist deshalb eng: erforderlich sind eine aktivierte Token-Exchange-Funktion und mindestens zwei vertrauenswürdige externe Issuer. Da Token Exchange ausschließlich in Enterprise-Umgebungen verfügbar und zudem noch als Vorschau markiert ist, ist laut Quelltext nur ein kleiner, spezifischer Kreis exponiert, vor allem OEM-Deployments mit unterstützter Mehr-Issuer-Konfiguration.
Offen bleibt laut Advisory, wie ein Angreifer an ein geeignetes Token gelangt. Dort heißt es nur, dass ein solches Token erlangt werden könne. Ob ein gewöhnlicher Nutzer bei einem vertrauenswürdigen Issuer Einfluss auf den zugewiesenen „sub“-Wert hat, beantwortet der öffentliche Eintrag nicht. GitHub bewertet die Schwachstelle als CNA mit 7,6 nach CVSS 4.0 und stuft sie damit als hoch ein; der Vektor vermerkt vorhandene Angriffsanforderungen. NVD bewertet dieselbe Lücke mit 6,8 nach CVSS 3.1 als mittel und führt CWE-287 sowie CWE-346 auf. CISA verzeichnete in seiner SSVC-Bewertung vom 13. Juli keine Ausnutzung, und The Hacker News fand bei Recherchen am 16. Juli keinen öffentlich verfügbaren Proof of Concept.
Zwei Wochen vor dem Fix für CVE-2026-59208 hatten die Maintainer bereits CVE-2026-54305 geschlossen, ebenfalls eine Enterprise-Schwachstelle. Diese erlaubte es jedem authentifizierten Nutzer, über die Dynamic-Credentials-Endpunkte gespeicherte OAuth-Token anderer Benutzer zu überschreiben oder zu widerrufen. Laut Quelltext handelte es sich dabei um einen fehlenden Eigentumscheck und nicht um einen Fehler in der Identitätsbindung.
Wer nicht sofort patchen kann, sollte laut Advisory zunächst die eigene Konfiguration prüfen: N8N_TOKEN_EXCHANGE_TRUSTED_KEYS enthält die vertrauenswürdigen Signaturschlüssel, und ein separates Vorschau-Flag steuert, ob Token Exchange überhaupt aktiv ist. Als Zwischenmaßnahme nennt n8n, die Konfiguration auf einen einzelnen vertrauenswürdigen Issuer zu reduzieren oder die Funktion ganz abzuschalten. Zugleich weist das Advisory darauf hin, dass beide Schritte das Risiko nicht vollständig beseitigen. Nach n8ns eigener Eingrenzung sind Instanzen mit deaktiviertem Token Exchange jedoch nicht betroffen.
Auffällig ist zudem, dass die Korrektur laut The Hacker News in den Release Notes nicht erwähnt wird. Die Änderungsprotokolle zu 2.27.4 und 2.28.1 nennen demnach unter anderem eine Korrektur für Python-Importe, ein Upgrade des Google-Ads-Knotens, eine Prüfung für KI-Workflows und eine Änderung beim Erstellen von Knoten – nicht aber den Identitätsfehler. Die eigentliche Information steckt im Advisory.