Wenn n8n API Tokens in öffentlichen GitHub-Commits auftauchen, ist das Risiko nicht mit dem ersten Treffer beendet. Forschende haben gezeigt, dass solche Schlüssel in einer beträchtlichen Zahl von Instanzen weiterhin akzeptiert wurden – und dass Angreifer dann gängige REST-Funktionen nutzen können, um Daten und nachgelagerte Zugangsdaten zu gefährden. Dabei war kein Exploit einer n8n-Schwachstelle nötig: Ein gültiger Token reicht oft, um sich als legitimer Nutzer zu verhalten.
Im Folgenden ordnen wir ein, wie die Exposition entstand, warum die Tokens so lange funktionierten, welche Daten sichtbar werden können und welche Schutzmaßnahmen Unternehmen priorisieren sollten.
Warum n8n überhaupt ein attraktives Ziel ist
n8n ist eine Open-Source-Plattform für Workflow-Automatisierung mit Low-Code-Ansatz und vielen Integrationen. Unternehmen verwenden sie, um interne Tools zu verbinden, Pipelines zu automatisieren, Geschäftslogik abzubilden und API-Ketten orchestrieren zu lassen – häufig quer durch Datenbanken, Code-Repositories, Cloud-Umgebungen, KI-Dienste und Support-Systeme.
Die Plattform kann selbst gehostet oder über n8n.cloud betrieben werden. Ein n8n-Workflow besteht aus Knoten (Nodes), die Eingaben verarbeiten, externe Dienste ansprechen oder Trigger enthalten, etwa Webhooks oder zeitgesteuerte Auslösungen. Für den Zugriff auf externe Systeme nutzt n8n gespeicherte Credentials wie API-Keys, Tokens und Datenbankpasswörter.
Token-Exposition: Wie aus GitHub ein Login wird
GitGuardian hat öffentliche GitHub-Commits systematisch nach n8n API Tokens durchsucht, die seit April 2025 gefunden wurden. Zu jedem identifizierten Token wurde der dazugehörige n8n-Hostname aus dem Commit extrahiert. Anschließend wurde mit einer read-only Anfrage geprüft, ob die Instanz den Schlüssel noch akzeptiert.
Insgesamt wurden 4.576 eindeutige Credentials in Verbindung mit 1.255 Hostnamen entdeckt. Von 896 erreichbaren Instanzen zum Zeitpunkt des Tests akzeptierten 321 mindestens einen geleakten Token. Das entspricht rund 36% der erreichbaren Instanzen und etwa 26% aller Hostnamen aus den Commits.
Die Botschaft ist klar: Die Veröffentlichung eines Tokens bedeutet nicht automatisch, dass er sofort ungültig ist. Für Angreifer ist entscheidend, dass eine betroffene Instanz ihn weiterhin als Authentifizierung akzeptiert.
Mehr als n8n: Warum das auch nachgelagerte Systeme trifft
n8n ist nicht nur ein einzelnes Programm. Es ist ein Vermittler zwischen Systemen. Ein ausreichend privilegierter Token kann daher mehr ausrichten als nur „Workflow-Daten anzusehen“.
Je nach Berechtigungen kann ein Token etwa Workflow-Definitionen und Ausführungsdaten offenlegen. Darüber hinaus kann er es ermöglichen, dass n8n gespeicherte Credentials im Namen des Angreifers verwendet. In manchen Konstellationen kann das sogar dazu führen, dass der eigentliche Credential-Wert aus einer laufenden Aktion heraus extrahiert wird.
Die Gefahr ist somit „systemübergreifend“: Der Schaden hängt nicht allein von n8n ab, sondern davon, welche Integrationen und Konten ein bestimmter n8n-Zugriff umfasst.
Warum geleakte n8n API Tokens oft lange gültig bleiben
Ein n8n API Key ist ein signiertes JSON Web Token (JWT) mit dem Audience-Eintrag aud = public-api. Beim Decoding lässt sich u. a. eine iat-Angabe (Ausstellzeit) sehen.
Ein wichtiger Punkt: Viele der im Projekt gefundenen Keys enthielten keine explizite Ablaufzeit (exp). Zwar führte n8n laut Bericht ab Version 1.78.0 einen Default-Timeout von 30 Tagen ein (Februar 2025), doch die gefundenen Tokens waren häufig zuvor generiert worden. Dadurch konnten Schlüssel aus älteren Zeiträumen weiterhin nutzbar bleiben, bis sie gelöscht oder explizit widerrufen wurden.
Auch anders als bei klassischen „selbstvalidierenden“ JWTs reicht die Signatur allein nicht. Der Token muss zusätzlich noch in der n8n-Datenbank existieren. Konsequenz: Ein Token, der im öffentlichen Repo landet, bleibt gefährlich, solange die Instanz ihn nicht entfernt hat.
Woran man die Token erkennen konnte: Hostname und Schlüssel zusammen
Damit ein geleakter Schlüssel praktisch nutzbar ist, muss der Angreifer wissen, welche Instanz ihn akzeptiert. In den untersuchten GitHub-Commits tauchten Token oft direkt zusammen mit dem Hostnamen auf.
Typische Beispiele waren Umgebungsdateien wie .env, etwa mit N8N_URL und N8N_API_KEY. Zusätzlich wurden Muster gefunden, die mit Permission-Dateien für Claude Code zusammenhängen. In solchen Dateien konnten sowohl die Instanz-URL als auch der API-Key in Curl-Kommandos oder Konfigurationsartefakten landen.
Weil Hostname und Token somit häufig gemeinsam im selben Commit existierten, war keine aufwendige Infrastruktur-Ermittlung nötig.
Welche Informationen ein authentifizierter Token liefert
Ein n8n API Tokens erlaubt Zugriff entsprechend der Rechte des Nutzers, der den Key erstellt hat. Viele der gefundenen Tokens wirkten wie Administrator- oder Instanzbesitzer-Zugriffe, also genau die Rollen, die besonders weitreichende Daten sehen können.
Je nach Account-Berechtigung kann die öffentliche REST-API beispielsweise liefern:
- Benutzerinformationen (z. B. Nutzernamen, E-Mail-Adressen, Account-Erstellzeit, Einladungsstatus)
- Workflow-Definitionen inkl. Node-Konfiguration und auch Code in „Code“-Nodes (z. B. JavaScript/Python), außerdem SQL-Abfragen und ggf. direkt hinterlegte Secrets in Parametern
- Credential-Metadaten (Namen, Typen, Sharing-Hinweise – jedoch nicht zwingend die geheimen Werte selbst)
- Ausführungshistorie, bei der bei Parametern wie includeData=true vollständige Eingaben und Ausgaben sichtbar werden können
- Daten aus Tabellen, sofern sie dem authentifizierten Nutzer zugänglich sind
- Variablen (inkl. Inhalt), wobei diese teils auf Owner/Admins beschränkt sind
Besonders heikel sind Workflow-Definitionen, weil sie im Klartext zeigen können, wie Automationen aufgebaut sind und welche Inhalte während der Laufzeit verarbeitet werden. Selbst wenn das Credential-Endpoint keine Rohwerte preisgibt, können nachgelagerte Schritte über die Plattform dennoch zu einem größeren Abfluss führen.
Ein Audit-Endpoint als „Angriffskarte“
n8n besitzt einen Audit-Endpunkt, der für einen authentifizierten Nutzer einen Sicherheitsbericht der Instanz zurückgeben kann. Im Test wurde dafür eine Anfrage mit dem Token an den Audit-URL verwendet.
Der Response kann u. a. Hinweise enthalten zu:
- möglichen SQL-Injection-Risiken in Workflows
- Nodes mit Dateisystemzugriff
- unbehandelten/ungesicherten Webhooks
- der laufenden n8n-Version (zur Zuordnung zu bekannten Schwachstellen)
- ungenutzten Credentials
- High-Risk- oder Community-Installationen von Nodes
- aktivierten Sicherheitsfunktionen
- Allow-/Blocklisten von Nodes sowie Telemetrieeinstellungen
Für legitime Administratoren unterstützt das die Überprüfung. Für Angreifer kann es jedoch zur Priorisierung von Angriffspfaden werden: Welche Stellen zuerst prüfen, welche Workflows gezielt anstoßen, welche Daten besonders wahrscheinlich sind.
Vier reale Angriffstechniken – ohne CVE-Exploitation
GitGuardian hat die folgenden Schritte nicht gegen fremde Systeme im Wild durchgeführt, sondern in einer kontrollierten n8n-Umgebung nachgestellt. Ziel war zu zeigen, wie man vom geleakten Token zu größerer Datenausleitung und Credential-Missbrauch gelangt, allein mit dokumentierten REST-Funktionen und normalen HTTP-Anfragen.
Die Testumgebung enthielt bewusst konstruierten Schwachstellen:
- Ein Webformular speicherte eingereichte Daten in einer Daten-Tabelle, die über Workflows zugänglich war
- Ein OpenAI-Node verarbeitete Eingaben über ein gespeichertes Credential-Objekt
- Ein HTTP Request Node veröffentlichte Outputs nach GitHub, wobei ein Token in Node-Parametern hartkodiert war
Technik 1: Instanz auflisten und Inhalte „lesen“
Mit einem read-only Zugriff konnten zunächst Nutzende und Workflows aufgezählt werden. Insbesondere wurden vollständige Workflow-Definitionen geladen. Wenn in einem Workflow ein HTTP Request Node ein GitHub-Token in Klartext enthielt, wurde diese Information direkt sichtbar, ohne dass der Workflow geändert werden musste.
Technik 2: Gespeicherte OpenAI-Credentials verwenden
Über das Credentials-Listing ließ sich ein Credential-Objekt mit passendem Namen und Typ identifizieren. Der konkrete geheime Schlüssel war zwar nicht im Listing selbst enthalten. Dennoch konnte ein eigener Workflow mit einem Schedule-Trigger gestartet werden, der den OpenAI Node über das vorhandene Credential referenzierte.
Durch die Kombination aus getaktetem Trigger und dem Abruf vollständiger Execution-Daten (inkl. Output) konnten Antworten im Klartext ausgelesen werden – ohne jemals den Credential-Wert direkt zu sehen.
Technik 3: Daten aus einer Tabelle extrahieren
Ähnlich lief das bei tabellarischen Daten: Ein angepasster Workflow sollte per Schedule alle Zeilen aus einer Data-Table abrufen. Anschließend konnte die Execution mit eingeschlossenen Daten ausgelesen werden. Im Test führte das dazu, dass mehrere Datensätze inkl. personenbezogener Inhalte (z. B. Namen, E-Mail-Adressen) sichtbar wurden.
Technik 4: Roh-Credential extrahieren
Die letzte Technik ging einen Schritt weiter: Anstatt nur Outputs zu lesen, wurde ein HTTP Listener gestartet. Ein Workflow veranlasste dann den HTTP Request Node, Requests an den eigenen Listener zu senden und dabei die gespeicherte OpenAI Credential als Authentifizierung zu verwenden. Dadurch wurde der Credential-Wert in einem Authorization-Header bei ausgehenden Requests übertragen und vom Listener erfasst.
Danach wurde der bösartige Workflow wieder entfernt. Das hatte eine weitere Konsequenz: Aus der n8n-Oberfläche konnten die zugehörigen Execution-Records entfernt sein, was die forensische Aufklärung erschweren kann.
Warum die „Blast Radius“-Logik so gefährlich ist
Die Demonstration zeigt nicht nur eine abstrakte Schwachstelle, sondern eine Angriffskette, die mit normalen Funktionen entsteht:
- Token akzeptieren lassen
- Nutzer, Workflows und Sicherheitskonfiguration enumerieren
- gespeicherte Credentials identifizieren und nutzen
- Workflow-Zugriff auf Daten auslesen
- und im Extremfall Secrets über ausgehende Requests abgreifen
Damit wird deutlich, weshalb Automatisierungsplattformen besonders große Auswirkungen haben können: Sie liegen im Zentrum vieler Integrationen und authentifizieren wiederholt gegenüber externen Diensten.
Reale Muster: Bestätigte Beispiele aus der Untersuchung
Die kontrollierte Ausarbeitung war nicht völlig theoretisch. Im Forschungszeitraum wurden auch reale Instanzen mit ähnlichen Expositionsmustern gesehen. Ein Workflow konnte beispielsweise bei jeder Ausführung seine eigenen Definitionen in ein öffentliches GitHub-Repository sichern. Dabei war ein SSH Deployment Key in einem Node hard-coded, und ältere Workflow-Versionen im Git-Verlauf enthielten denselben Schlüssel.
Das bedeutet: Durch die Automatisierung wurde sensitive Konfiguration über die Zeit regelmäßig „repliziert“, statt sie nur einmalig zu exponieren.
Reaktion auf Meldungen: Nicht überall schnell und umfassend
Die Forschenden versuchten, betroffene Stellen verantwortungsvoll zu informieren. Bei insgesamt sieben Organisationen meldeten sie die Findings. Einige Hosting-Anbieter und Unternehmen reagierten nicht. Insgesamt wurde nur in einem Fall innerhalb des Berichtszeitraums sichtbar, dass das Problem anerkannt und schnell behoben wurde: Dort wurde eine Belohnung gezahlt und der Token unmittelbar widerrufen.
Auch gegenüber n8n wurden während der Recherche Berichte übermittelt. Laut Bericht bestätigte n8n, die Punkte zu kennen und sie adressieren zu wollen; die Reports wurden anschließend geschlossen. Zum Veröffentlichungszeitpunkt war jedoch nicht unabhängig verifiziert, ob die entsprechenden Fixes bereits live ausgeliefert waren.
Praktische Takeaways für Unternehmen
Ein n8n API Tokens-Leck ist selten nur ein einzelnes Credential-Problem. Wenn der Token privilegiert ist, kann er Workflow-Definitionen, Code- und Dateninhalte sowie Ausführungsergebnisse zugänglich machen. Zudem kann er den Missbrauch gespeicherter Credentials erlauben – bis hin zu einer Extraktion von Rohwerten über ausgehende Requests.
Für die Verteidigung gilt daher: Das Widerrufen des betroffenen Tokens ist der erste Schritt, aber nicht zwingend der letzte. Unternehmen sollten außerdem prüfen, welche Workflows der Zugriff hätte auslösen können, welche Daten sichtbar wären und welche verbundenen Systeme betroffen sein könnten. Dazu gehört auch das Rotieren nachgelagerter Zugangsdaten, falls eine Verwendung nicht sicher ausgeschlossen werden kann.
Zusätzlich sollten Teams die n8n-Instanz auf unautorisierte Änderungen prüfen und Tokens so absichern, dass sie nicht über öffentliche Repositories landen – etwa durch saubere Secret-Handling-Prozesse und konsequentes Credential-Store-Verhalten statt Hardcoding in Node-Parametern.
Fazit: Gerade weil n8n Automationen zwischen vielen Systemen vermittelt, kann ein geleakter Schlüssel eine breite Angriffsspur eröffnen. Entscheidend ist, schnell zu revoken, die Integrationskette zu bewerten und die betroffenen Datenflüsse sowie nachgelagerten Credentials systematisch zu bereinigen.
Quelle: https://thehackernews.com/2026/08/leaked-n8n-api-tokens-exposed-live.html
