n8n ist eine Open-Source-Plattform für Low-Code-Workflows mit Unterstützung für KI-Agenten und Hunderten eingebauten Integrationen. Sie kann selbst betrieben oder über n8n.cloud genutzt werden. Workflows bestehen aus Knoten, die Daten verarbeiten, Code ausführen oder mit externen Diensten über gespeicherte Zugangsdaten wie API-Schlüssel, Tokens oder Datenbank-Passwörter arbeiten. Diese Geheimnisse liegen zwar verschlüsselt vor, müssen aber bei der Ausführung von Workflows entschlüsselt werden. Laut GitGuardian kann ein Angreifer mit ausreichend weitreichenden API-Rechten neue Workflows anlegen und die Instanz dazu bringen, vorhandene Zugangsdaten in seinem Auftrag zu verwenden.
Für die Untersuchung sammelte GitGuardian nach eigenen Angaben alle n8n-API-Tokens, die das öffentliche Monitoring seit April 2025 in öffentlichen GitHub-Commits gefunden hatte. Die Pipeline extrahierte jeweils den mit dem Token eingecheckten n8n-Hostnamen, schickte eine schreibgeschützte Validierungsanfrage an die zugehörige Instanz und wertete die Antwort aus. Zusätzlich prüfte GitGuardian auch n8n-Model-Context-Protocol-API-Schlüssel aus demselben Commit-Bestand. Von 372 identifizierten MCP-Tokens waren zum Testzeitpunkt noch sieben gültig, also rund 2 Prozent.
Ein n8n-API-Schlüssel ist ein signiertes JSON Web Token mit dem Zielgruppenmerkmal „public-api“. Ältere Schlüssel enthielten laut GitGuardian häufig kein Ablaufdatum. n8n führte in Version 1.78.0 im Februar 2025 zwar eine standardmäßige Gültigkeit von 30 Tagen ein, viele der in der Untersuchung gefundenen Tokens waren jedoch ohne Ablaufdatum erzeugt worden. Ein vor Monaten in GitHub veröffentlichter Schlüssel kann deshalb nutzbar bleiben, bis er ausdrücklich gelöscht oder widerrufen wird. Praktisch reicht die Signatur allein nicht aus: Das Token muss weiterhin in der n8n-Datenbank vorhanden sein.
Die Forscher beschreiben auch, warum sich solche Tokens leicht zuordnen lassen. In öffentlichen Commits tauchten Hostname und Token häufig gemeinsam auf, etwa in .env-Dateien. Ein neueres Muster betraf Dateien mit Berechtigungen für Claude Code, insbesondere .claude/settings.json oder .claude/settings.local.json. Wenn Anwender Claude Code für die Interaktion mit n8n konfigurieren, können dort sowohl die Instanz-URL als auch der API-Schlüssel direkt in einem freigegebenen curl-Befehl stehen.
In einer kontrollierten n8n-Umgebung demonstrierte GitGuardian vier praktische Techniken. Zunächst ließen sich per GET /api/v1/users vier Konten abrufen und per GET /api/v1/workflows neun vollständige Workflow-Definitionen. In einem Workflow fanden die Forscher im Parameter eines HTTP-Request-Knotens einen GitHub-Token im Klartext.
Anschließend nutzten sie gespeicherte Zugangsdaten indirekt. Über GET /api/v1/credentials ließ sich etwa ein Objekt namens „OpenAI account“ auflisten, ohne den eigentlichen Schlüssel anzuzeigen. Die Forscher erstellten einen Workflow mit Schedule-Trigger und OpenAI-Knoten, verwiesen auf die Zugangsdaten per Kennung und aktivierten den Workflow. Über GET /api/v1/executions?includeData=true erhielten sie danach den vollständigen Ausführungsdatensatz, einschließlich der Klartextantwort des OpenAI-Knotens. So konnten sie beliebige OpenAI-Anfragen mit den gespeicherten Zugangsdaten der Instanz ausführen, ohne den Schlüsselwert selbst zu kennen.
Dasselbe Prinzip funktionierte laut GitGuardian auch für Datenabflüsse aus Tabellen. Ein Workflow mit Schedule-Trigger und Data-Table-Knoten rief alle Zeilen ab; Sekunden später lieferte der Ausführungsdatensatz sämtliche Datensätze im Klartext zurück. In der Demonstration wurden vier Zeilen exfiltriert, darunter Namen, E-Mail-Adressen, Formularantworten und Verarbeitungsstatus. Danach wurde der Workflow gelöscht.
Die vierte Technik extrahierte den zugrunde liegenden Geheimniswert selbst. Dazu richteten die Forscher einen HTTP-Listener ein und erstellten einen Workflow mit Schedule-Trigger und HTTP-Request-Knoten. Dieser Knoten kann laut Bericht eine gespeicherte n8n-Zugangsdatenkonfiguration zur Authentifizierung verwenden, aber Anfragen an beliebige URLs senden. Als der Workflow lief, hängte n8n den gespeicherten Wert als Bearer-Token an den ausgehenden Authorization-Header. Der Listener fing den rohen API-Schlüssel daraufhin ab.
GitGuardian betont, dass diese Techniken nicht gegen fremde produktive Systeme ausgeführt wurden. Allerdings fanden die Forscher während der Recherche reale n8n-Instanzen mit ähnlichen Mustern. In einem Fall sicherte ein Workflow seine eigenen Definitionen automatisch in ein öffentliches GitHub-Repository; ein SSH-Deployment-Schlüssel war direkt in einem Knoten fest einkodiert. Die Git-Historie des Repositoriums enthielt frühere Versionen sämtlicher Workflows, und der SSH-Schlüssel blieb gültig.
Parallel verweist der Bericht auf den allgemeinen Sicherheitszustand des Ökosystems. Über Shodan seien mehr als 100.000 n8n-Instanzen sichtbar, und seit Januar 2026 seien mehr als 50 Sicherheitswarnungen veröffentlicht worden. Zum Stand vom 31. März 2026 liefen 58 Prozent der gescannten Instanzen auf einer Version, die von mindestens einer bekannten Sicherheitswarnung betroffen war. CVE-2025-68613, eine Expression-Injection-Schwachstelle mit einem CVSS-Wert von 9,9, wurde am 11. März 2026 in den Katalog der Known Exploited Vulnerabilities der US-Behörde CISA aufgenommen.
GitGuardian versuchte nach eigenen Angaben eine verantwortungsvolle Offenlegung bei sieben Organisationen. Ein Hosting-Anbieter reagierte nicht, ebenso drei von vier einzelnen Unternehmen. Ein Unternehmen mit Bug-Bounty-Programm bestätigte den Bericht, zahlte 1.200 US-Dollar Prämie und widerrief die Zugangsdaten umgehend. GitGuardian meldete außerdem mehrere Punkte direkt an n8n. Das Unternehmen habe die Meldungen bestätigt, erklärt, die Probleme zu kennen und beheben zu wollen, und die Berichte anschließend geschlossen. Zum Veröffentlichungszeitpunkt konnte GitGuardian nach eigenen Angaben nicht unabhängig bestätigen, dass die zugehörigen Korrekturen bereits ausgerollt waren.