In der Workflow-Automatisierungsplattform n8n wurde die Schwachstelle CVE-2026-59208 entdeckt, die es einem Angreifer ermöglicht, sich ohne Kenntnis des Passworts unter einem fremden Benutzerkonto zu authentifizieren. Das Problem betrifft Enterprise-Instanzen mit aktivierter Funktion zum token exchange und mindestens zwei vertrauenswürdigen externen JWT-Issuern. Das System ordnete ein eingehendes Token einem lokalen Benutzer ausschließlich anhand des Werts des Claims sub zu und ignorierte iss – den Issuer des Tokens. Der Patch wurde am 24. Juni in den Versionen 2.27.4 und 2.28.1 veröffentlicht; Administratoren betroffener Konfigurationen müssen aktualisieren oder die Zahl der vertrauenswürdigen Issuer auf einen begrenzen.
Kern der Schwachstelle: halbe Kennung statt vollständiger ID
Die Funktion token exchange in n8n implementiert die Spezifikation RFC 8693 und ist für OEM-Partner gedacht, die n8n in ihre Produkte integrieren. Der Partner signiert einen kurzlebigen JWT mit seinem Schlüssel, n8n überprüft die Signatur anhand des vorab konfigurierten öffentlichen Schlüssels aus der Umgebungsvariablen N8N_TOKEN_EXCHANGE_TRUSTED_KEYS, ordnet die Claims einem lokalen Benutzerkonto zu und lässt den Benutzer ohne erneute Authentifizierung passieren.
Das Problem lag in der Logik dieser Zuordnung. Gemäß RFC 7519 ist der Wert des Claims sub nur im Kontext eines bestimmten Issuers (iss) eindeutig garantiert. Die korrekte Benutzerkennung ist das Paar iss + sub. n8n verwendete jedoch für die Verknüpfung nur sub und stützte sich damit faktisch auf die Hälfte der Kennung.
Die praktische Folge: Wenn zwei vertrauenswürdige Issuer (A und B) Tokens mit demselben Wert sub für unterschiedliche Benutzer ausstellen, ermöglicht ein gültiges Token des Issuers A die Authentifizierung als ein Benutzer, der unter Issuer B registriert ist. Das Passwort des Opfers wird dabei nicht verwendet – das System vertraut vollständig auf die Zuordnung über sub.
Einschätzung der Schwere und Exploit-Status
Die Schweregradeinschätzungen verschiedener Quellen gehen auseinander. GitHub als CNA vergab für die Schwachstelle CVSS 4.0 – 7.6 (High). Die NVD bewertete sie nach CVSS 3.1 mit 6.8 (Medium) und ordnete sie den Schwachstellenklassen CWE-287 (fehlerhafte Authentifizierung) und CWE-346 (unzureichende Prüfung der Quelle) zu. Die Abweichung ergibt sich sowohl aus den Unterschieden zwischen den CVSS-Methodiken 4.0 und 3.1 als auch aus der unterschiedlichen Interpretation der Angriffsbedingungen.
Die Schwachstelle ist nicht im CISA-Katalog der Known Exploited Vulnerabilities aufgeführt. Nach aktuellem Kenntnisstand gibt es keine öffentlichen Proof-of-Concepts (PoC) und keine bestätigten Fälle einer Ausnutzung.
Wer ist bedroht
Der Wirkungsbereich ist eng, doch für betroffene Konfigurationen sind die Folgen gravierend. Die Schwachstelle tritt nur bei gleichzeitiger Erfüllung dreier Bedingungen auf:
- Enterprise-Lizenz für n8n;
- aktivierte token-exchange-Funktion (laut Dokumentation nach wie vor im Preview-Status);
- Konfiguration mit zwei oder mehr vertrauenswürdigen externen Token-Issuern.
Dies ist ein typisches Szenario bei OEM-Deployments, in denen mehrere Partner n8n in ihre Plattformen integrieren. Für solche Instanzen bedeutet die Schwachstelle praktisch die Möglichkeit einer Cross-Tenant-Kontoübernahme – ein Benutzer eines Partners kann Zugriff auf Daten und Workflows eines Benutzers eines anderen Partners erhalten.
Offen bleibt die Frage nach der praktischen Umsetzbarkeit des Angriffs: Im Advisory wird nicht klargestellt, ob ein normaler Benutzer eines vertrauenswürdigen Issuers Einfluss auf den Wert von sub in seinem Token nehmen kann. Der CVSS-Vektor von GitHub weist auf zusätzliche Anforderungen an den Angriff hin, legt diese jedoch nicht offen.
Kontext: zweite Enterprise-Schwachstelle innerhalb von zwei Wochen
Zwei Wochen vor Veröffentlichung des Patches für CVE-2026-59208 haben die n8n-Entwickler CVE-2026-54305 behoben – eine weitere Schwachstelle, die auf Enterprise-Funktionalität beschränkt war. Sie erlaubte jedem authentifizierten Benutzer, über die Dynamic-Credentials-Endpunkte OAuth-Tokens anderer Benutzer zu überschreiben oder zu widerrufen, da die Prüfung des Besitzers der Ressource fehlte. Zwei unterschiedliche Schwachstellen – Identitätszuordnung und Zugriffskontrolle auf Ressourcen – weisen beide auf eine unzureichende Reife der Autorisierungsprüfungen in den Enterprise-Komponenten der Plattform hin.
Empfehlungen zur Behebung
Betroffen sind alle n8n-Versionen unterhalb von 2.27.4 sowie Version 2.28.0. Die Korrektur ist ab den Versionen 2.27.4 und 2.28.1 verfügbar.
- Update – vorrangige Maßnahme. Installieren Sie mindestens Version 2.27.4 oder 2.28.1, vorzugsweise den jeweils neuesten stabilen Build.
- Falls ein Update nicht sofort möglich ist – reduzieren Sie die Liste der vertrauenswürdigen Issuer in
N8N_TOKEN_EXCHANGE_TRUSTED_KEYSauf einen Eintrag oder deaktivieren Sie die token-exchange-Funktion vollständig. Nach Aussage von n8n sind Instanzen mit deaktiviertem token exchange nicht verwundbar. - Prüfen Sie die Authentifizierungsprotokolle auf ungewöhnliche Logins – Sitzungen, in denen sich ein Benutzer über ein Token eines Issuers authentifiziert hat, aber Zugriff auf Ressourcen erhielt, die einem Konto eines anderen Issuers gehören.
Wichtiger Punkt: Weder im Changelog der Version 2.27.4 noch im Changelog der Version 2.28.1 wird die Korrektur nach aktuellem Kenntnisstand erwähnt. Die Information findet sich ausschließlich im Advisory. Organisationen, die Update-Entscheidungen ausschließlich auf Basis der Release Notes treffen, laufen Gefahr, diesen Patch zu übersehen.
Administratoren von n8n Enterprise mit aktivem token exchange und mehreren vertrauenswürdigen Issuern sollten das Update als dringlich betrachten. Selbst bei begrenztem Umfang der Schwachstelle machen die möglichen Folgen einer Ausnutzung – vollständige Kontoübernahme ohne Interaktion mit dem Opfer – jedes Zögern unangebracht. Prüfen Sie die aktuell eingesetzte Version, den Inhalt von N8N_TOKEN_EXCHANGE_TRUSTED_KEYS und entscheiden Sie: aktualisieren oder die Konfiguration einschränken.
