BERLIN / LONDON (IT BOLTWISE) – n8n hat einen Login-Sicherheitsfehler in seiner Enterprise-Token-Exchange-Implementierung geschlossen. Angreifer konnten demnach unter bestimmten Konfigurationen per JWT den sub-Claim ausnutzen und sich als Nutzer eines anderen Token-Ausstellers ausgeben. Betroffen sind Versionen unter 2.27.4 sowie 2.28.0; der Fix landete zuerst in 2.27.4 und 2.28.1. Entscheidend ist, ob Token Exchange aktiviert ist und ob mehr als ein externer Token-Issuer als vertrauenswürdig konfiguriert wurde.
n8n warnt mit CVE-2026-59208 vor einer Schwachstelle in seinem Enterprise-Workflow-Automationssetup: Beim Token-Exchange-Login gab die Plattform unter bestimmten Bedingungen die falsche Identität weiter. Das Problem betrifft Konfigurationen, in denen Token von mehreren externen Ausstellern (Issuers) gleichzeitig vertraut werden. Laut Beschreibung konnte ein gültiges JWT eines Issuers A mit einem sub-Claim, der zu einem Nutzer unter Issuer B gehört, den Login für genau diesen Nutzer B auslösen. Damit verschiebt sich der Fokus von klassischen Passwortrisiken hin zu einer Identitäts-Bindungsfrage in der JWT-Verarbeitung.
Technisch betrachtet nutzt n8n hier den Token-Exchange-Mechanismus aus RFC 8693, um OEM-Partnern einen zusätzlichen Login-Schritt zu ersparen. Der Partner signiert dafür einen kurzlebigen JWT mit seinem eigenen Schlüssel; n8n prüft anschließend die Signatur gegen eine konfigurierte Public-Key-Liste. Danach werden JWT-Claims mit lokalen Accounts gemappt. Der Fehler liegt nicht in der Signaturprüfung, sondern in der Entscheidung, welche Claim-Kombination die Konto-Identität eindeutig macht: n8n soll den sub-Claim allein verwendet haben und damit die iss-Information ignoriert haben. RFC 7519 stellt sub jedoch nur issuer-intern sicher.
Für die Einordnung lohnt ein Blick auf die Token-Identitätsmodelle etablierter IAM-Lösungen wie Keycloak oder Auth-Anbieter wie Okta: In der Praxis wird die Nutzerzuordnung häufig als Tupel modelliert, typischerweise aus iss plus sub, genau weil sub allein keine globale Eindeutigkeit garantiert. Der hier beschriebene Bug zeigt, wie leicht eine „korrekte“ Claims-Validierung trotzdem ins Leere laufen kann, wenn die lokale Identitätslogik die Spezifikationsgrenzen unterschreitet. Marktbeobachter sehen solche Fehler besonders in Enterprise-Integrationen, in denen mehrere Token-Aussteller gleichzeitig erlaubt werden und Teams zwischen OAuth-Konzepten, JWT-Claims und proprietären Account-Mappings wechseln.
Die Auswirkungen sind gleichzeitig gezielt und potenziell schwer: Der Fehler tritt nur auf, wenn Token Exchange in n8n Enterprise aktiviert ist und mindestens zwei externe Issuer als vertrauenswürdig hinterlegt sind. n8n ordnet Token Exchange selbst als Enterprise-only und noch im „preview“-Status ein, wodurch die Angriffsfläche kleiner bleibt als bei einer breit ausgerollten Funktion. Dennoch ist das Setting typisch für OEM-Deployments, in denen Hersteller und Kunden getrennte Authentifizierungssysteme betreiben. In der Bewertung rangiert CVE-2026-59208 laut CVSS 4.0 mit 7,6 im „high“-Bereich; demgegenüber gibt es für CVSS 3.1 eine niedrigere Einstufung durch NVD. Eine öffentliche Proof-of-Concept-Verifikation war zum Zeitpunkt der Recherche nicht auffindbar.
Der besonders kritische praktische Punkt liegt in der Angriffsannahme: Die Advisory lässt offen, wie ein Angreifer an ein entsprechendes Token gelangt. Unklar ist damit auch, ob ein normaler Nutzer innerhalb eines vertrauenswürdigen Issuers Einfluss auf den sub-Claim hat, den er im Token-Exchange-Prozess erhält. GitHub als zuständige CNA weist in der CVSS-Vectorbeschreibung attack requirements als vorhanden aus, ohne Details zu quantifizieren. Daneben erinnert die Historie an CVE-2026-54305 aus demselben Produktkontext: Dort ging es zwei Wochen vor dem Fix um die Möglichkeit, OAuth-Tokens anderer Nutzer über Dynamic Credentials zu überschreiben oder zu widerrufen. Obwohl es sich um einen anderen Fehlermechanismus (fehlende Ownership-Prüfung, nicht Identitätsbindung) handelt, zeigt die Gemengelage, wie sensibel diese „Enterprise-Auth“-Oberflächen sind.
Für den Betrieb ist das Upgrade-Patching zentral: CVE-2026-59208 betrifft Releases unter 2.27.4 und 2.28.0. Der Fix wurde zuerst in 2.27.4 sowie 2.28.1 eingespielt, und als unterster Fix-Stand gelten diese Versionen. Am 16. Juli trug das npm-Paket laut Paketständen 2.30.6 sowohl auf „latest“ als auch auf „stable“. Weil n8n nach eigenem Rhythmus regelmäßig neue Minor-Releases veröffentlicht, sollten Betreiber prüfen, welche Version ihr Deployment-Support-Zyklus zulässt, statt blind auf das Changelog zu vertrauen. Wichtig ist zusätzlich die Konfiguration: N8N_TOKEN_EXCHANGE_TRUSTED_KEYS steuert die vertrauenswürdigen Signierschlüssel, während eine separate Preview-Flag token exchange ein- oder ausknipst.
Falls ein Upgrade kurzfristig nicht möglich ist, empfiehlt sich eine Risiko-Reduktion über die Konfiguration: Entweder auf genau einen vertrauenswürdigen Issuer begrenzen oder Token Exchange deaktivieren, sofern das Geschäftsmodell es zulässt. Die Advisory beschreibt beides als kurzfristige Maßnahmen, ohne das Risiko vollständig „wegzuzaubern“. Das liegt auch daran, dass n8n die Identitätszuordnung als Fehlerquelle adressiert, nicht nur eine einzelne Auth-Option. Interessant ist außerdem, dass die Release Notes den Fix nicht explizit erwähnen; wer Entscheidungen nur aus den üblichen Release-Highlights ableitet, kann damit leicht an einer sicherheitsrelevanten Korrektur vorbeikommen.
In die Zukunft übersetzt heißt das für Enterprise-Teams: Token-Exchange-Funktionen sollten wie eine Identity-Gateway-Komponente behandelt werden. Sobald mehrere Issuer zulässig sind, gehört eine konsistente Identitäts-Generierung zum Standard, also die harte Kopplung von iss und sub (oder ein äquivalentes Schema mit eindeutigem Identifier). Daneben sollten Security-Teams die Logik für Credential- und OAuth-Endpunkte erneut gegen Ownership- und Bindungsfehler testen, weil ähnliche Oberflächen in kurzer Zeit wiederholt betroffen sein können. Für Entwickler entsteht hier auch eine Chance: Beim Aufbau von Integrationen lassen sich automatisierte Tests einführen, die bewusst kollidierende sub-Claims über verschiedene Issuer simulieren, um solche Fehler künftig früh abzufangen.
💳 Amazon-Kreditkarte mit 2.000 Euro Limit bestellen!
🔥 Heutige Hot Deals bei Amazon: Bis zu 80% Rabatte!
🎉 Amazon Haul-Store für absolute Schnäppchenjäger!
- ★ 23-stufiges KI-Go-Training – Für Spieler mit Grundkenntnissen der Regeln – Entwickelt als intelligenter Trainingspartner passt sich die KI Spielern von 18K bis 9D an. Ideal für alle, die die Grundregeln bereits beherrschen und ihr Spiel verbessern möchten.
- IHR EMOTIONALER AI-BEGLEITER: Eiliko ist mehr als nur ein Anhänger, es ist ein charismatischer KI-Freund. Mit einem dynamischen LED-Bildschirm, der eine Vielzahl von animierten Gesichtern und Ausdrucksformen anzeigt, reagiert er auf Ihre Interaktionen mit einzigartiger Persönlichkeit und Charme.
- NIEDLICHER BEGLEITER: Eilik ist der ideale Begleiter für Kinder und Erwachsene, die Haustiere, Spiele und intelligente Roboter lieben. Mit vielen Emotionen, Bewegungen und interaktiven Funktionen.
- 【XL-Größe für gedeihende Pflanzen】Geben Sie Ihren Pflanzen den Raum, den sie verdienen! Unser verbessertes, großes 13,7 cm großes Design bietet Platz für Pflanzen mit einem Durchmesser von bis zu 8,9 cm und damit deutlich mehr Platz für Wurzelwachstum und Pflanzengesundheit im Vergleich zu kleineren, veralteten Modellen. Die Produktabmessungen betragen 13,6 x 13,6 x 13,2 cm und das Gerät wiegt nur 355 g.
- V28 Update - JETZT MIT NEUEN FUNKTIONEN! Als Reaktion auf das Ladeproblem von Loona haben wir das automatische Aufladen 2.0 verbessert. Diese Optimierung hilft Loona, die Ladewege in verschiedenen Szenarien zu erkennen und anzupassen, um die Erfolgsquote beim automatischen Aufladen zu erhöhen. Mobile Hotspots können sich mit Loona verbinden und überwinden WLAN-Einschränkungen, sodass Sie jederzeit und überall mit Loona interagieren können.
- Die besten Bücher rund um KI & Robotik!
- Die besten KI-News kostenlos per eMail erhalten!
- Zur Startseite von IT BOLTWISE® für aktuelle KI-News!
- IT BOLTWISE® kostenlos auf Patreon unterstützen!
- Aktuelle KI-Jobs auf StepStone finden und bewerben!
- Künstliche Intelligenz: Dem Menschen überlegen – wie KI uns rettet und bedroht | Der Neurowissenschaftler, Psychiater und SPIEGEL-Bestsellerautor von »Digitale Demenz«
Du hast einen wertvollen Beitrag oder Kommentar zum Artikel "n8n: Token-Exchange-Fehler (CVE-2026-59208) kann Nutzer-Accounts über JWT-Sub verwechseln" für unsere Leser?
#Sophos
#AmazonPrime
#Bestseller
Es werden alle Kommentare moderiert!
Für eine offene Diskussion behalten wir uns vor, jeden Kommentar zu löschen, der nicht direkt auf das Thema abzielt oder nur den Zweck hat, Leser oder Autoren herabzuwürdigen.
Wir möchten, dass respektvoll miteinander kommuniziert wird, so als ob die Diskussion mit real anwesenden Personen geführt wird. Dies machen wir für den Großteil unserer Leser, der sachlich und konstruktiv über ein Thema sprechen möchte.
Du willst nichts verpassen?
Du möchtest über ähnliche News und Beiträge wie "n8n: Token-Exchange-Fehler (CVE-2026-59208) kann Nutzer-Accounts über JWT-Sub verwechseln" informiert werden? Neben der E-Mail-Benachrichtigung habt ihr auch die Möglichkeit, den Feed dieses Beitrags zu abonnieren. Wer natürlich alles lesen möchte, der sollte den RSS-Hauptfeed oder IT BOLTWISE® bei Google News wie auch bei Bing News abonnieren.
Nutze die Google-Suchmaschine für eine weitere Themenrecherche: »n8n: Token-Exchange-Fehler (CVE-2026-59208) kann Nutzer-Accounts über JWT-Sub verwechseln« bei Google Deutschland suchen, bei Bing oder Google News!