Auf den Punkt: n8n validierte eingehende JWTs nur anhand des sub-Claims und ignorierte den iss-Claim, wodurch Token verschiedener Issuer vermischt werden konnten.
n8n hat eine Anfälligkeit in der JWT-Validierung behoben, die es Angreifern ermöglichte, sich mit Token eines anderen Identity-Issuers als fremde Benutzer anzumelden. Das Problem trat auf Enterprise-Instanzen auf, die mehrere externe Token-Issuer vertrauten.
Die Schwachstelle im Detail: Auf n8n-Enterprise-Instanzen, die mehrere externe Token-Issuer als vertrauenswürdig einstufen, wurde ein eingehender JWT nur nach dem sub-Claim (Subject) geprüft. Der iss-Claim (Issuer) blieb unberücksichtigt. Ein gültiger Token von Issuer A mit einem sub-Wert, der einem Benutzer unter Issuer B zugeordnet war, führte daher zum Login als dieser Benutzer — ohne dass ein Passwort nötig war.
Sicherheitsimplikation für CISOs: Diese Fehler-Konfiguration ermöglichte Token-Mix-up-Attacken und konnte zu unbefugtem Zugriff auf Fremdbenutzerkonen führen. Besonders kritisch ist dies in Umgebungen, in denen mehrere Identity-Provider in Föderationen oder Hybrid-Szenarien zusammenwirken. Angreifer mit Zugriff auf einen beliebigen Token-Issuer hätten Konten aus anderen Organisationen oder Vertrauensdomänen übernehmen können.
Überprüfung und Remediation: CISOs sollten n8n-Enterprise-Instanzen, die mehrere externe Issuer verwenden, umgehend auf patched-Versionen aktualisieren und das Deployment überprüfen. JWT-Validierung muss immer sowohl den iss- als auch den sub-Claim berücksichtigen, um Cross-Issuer-Wechsel auszuschließen.
Quelle: thehackernews.com · Erschienen 16. Juli 2026
Lumi AI News — KI-assistierte Kuratierung gemaess Art. 50 EU AI Act. Paraphrase und Klassifikation durch Lumi News Pipeline v1.7.3.