Auf GitHub offengelegte n8n-API-Token: 321 Instanzen akzeptierten kompromittierte Zugangsdaten

Authentifizierter Zugriff öffnet den Weg zu verbundenen Systemen

GitGuardian hat 4.576 n8n-API-Token entdeckt, die in 5.469 GitHub-Commits veröffentlicht wurden und sich 1.255 Hostnamen zuordnen ließen.

Von den 896 erreichbaren Instanzen akzeptierten 321 mindestens ein kompromittiertes Token. Das entspricht 36 % der zugänglichen Instanzen und rund 26 % der ermittelten Hostnamen.

Dafür ist kein Ausnutzen einer n8n-Schwachstelle erforderlich. Ein noch gültiges Token und die dokumentierten REST-APIs können bereits ausreichen, um authentifizierten Zugriff zu erhalten.

Workflows, Zugangsdaten und Integrationen im Angriffsradius

n8n ist eine Low-Code-Plattform zur Automatisierung von Workflows, die selbst gehostet oder über n8n.cloud betrieben werden kann. Die Integrationen können Datenbanken, Repositories, Cloud-Umgebungen, KI-Dienste und interne Systeme verbinden.

In einer kontrollierten Umgebung reproduzierte GitGuardian vier Angriffstechniken. Ein Angreifer kann:

• Workflows und Ausführungsdaten auslesen;
• Automatisierungen erstellen oder verändern;
• in Workflows gespeicherte Zugangsdaten verwenden;
• die zugehörigen Werte unter bestimmten Konfigurationen auslesen;
• verbundene nachgelagerte Systeme erreichen.

Die Zugangsdaten werden im Ruhezustand mit N8N_ENCRYPTION_KEY verschlüsselt. Die Instanz muss sie während der Ausführung jedoch entschlüsseln. Der Schutz dieses Schlüssels bleibt daher entscheidend.

Außerdem wurden 372 MCP-Token gefunden, von denen 7 noch gültig waren. Diese Token können das Risiko erhöhen, wenn KI-Assistenten Workflows aufrufen oder mit der n8n-Umgebung interagieren.

Token ohne Ablaufdatum und veraltete Versionen

Ältere Token enthalten möglicherweise keinen exp-Claim und bleiben dadurch unbegrenzt gültig. n8n führte in Version 1.78.0, die im Februar 2025 veröffentlicht wurde, eine standardmäßige Gültigkeitsdauer von 30 Tagen ein. Diese Änderung macht zuvor erstellte Token jedoch nicht automatisch ungültig.

Das Risiko wird durch die öffentliche Erreichbarkeit der Instanzen verschärft: Über Shodan waren mehr als 100.000 Instanzen sichtbar. Zudem waren seit Januar 2026 mehr als 50 Sicherheitswarnungen verfügbar. Am 31. März 2026 liefen 58 % der analysierten Instanzen mit Versionen, die von mindestens einer Sicherheitswarnung betroffen waren.

Dazu zählt CVE-2025-68613 mit einem CVSS-Wert von 9,9, die am 11. März 2026 in den KEV-Katalog aufgenommen wurde. Für das auf gültigen Token basierende Szenario ist sie jedoch nicht erforderlich.

Sofortige Sperrung und Prüfung verbundener Systeme

Administratoren sollten:

1. offengelegte n8n- und MCP-Token widerrufen und neu erstellen;
2. öffentliche und private Repositories nach Token, Hostnamen und Hinweisen auf Zugangsdaten durchsuchen;
3. n8n auf Versionen aktualisieren, die nicht von den Sicherheitswarnungen betroffen sind;
4. kurze Gültigkeitsfristen und eine automatische Rotation einrichten;
5. die Internet-Exponierung begrenzen und den API-Zugriff filtern;
6. Workflows, Ausführungsprotokolle, Konten und nachgelagerte Systeme überprüfen;
7. N8N_ENCRYPTION_KEY schützen und die Berechtigungen der von Workflows verwendeten Zugangsdaten reduzieren.

Das Vorhandensein eines Tokens in einem historischen Commit sollte als Kompromittierung behandelt werden, auch wenn die Datei später entfernt wurde.