Sichern von Agenten-AI-Workflows in n8n: Von geleakten API-Schlüsseln bis zum Verschlüsselungsschlüssel-Kompromiss

Agentic AI erweitert die Sicherheitsgrenze der Workflow-Automatisierung. Ein n8n agentischer Workflow generiert nicht nur eine Antwort. Es verwendet gespeicherte Anmeldeinformationen, um über Source Control, Datenbanken, Cloud-Plattformen, KI-Anbieter und SaaS-Anwendungen hinweg zu agieren. Ein durchgesickerter n8n API-Schlüssel ist daher nur der Anfang des Angriffspfades. Im Zentrum dieses Zugangs steht eine einzige Wurzel des Vertrauens: die . Unsere Forschung untersuchte, wie sich ein Angreifer vom anfänglichen API-Zugriff auf diesen Schlüssel und die damit geschützten Anmeldeinformationen bewegen könnte. Wir fanden drei Schwächen in der Art und Weise, wie n8n Signier- und Sitzungsgeheimnisse ableitet, demonstrierten, wie schwache Verschlüsselungsschlüssel offline von öffentlichen Artefakten wiederhergestellt werden können, und identifizierten 129 internetzugängliche Instanzen mit bekannten schwachen Schlüsseln. Wir haben auch einen Angriff mit CVE-2026-25053 reproduziert, der es ermöglichte, einen API-Schlüssel, der mit einem ausreichend privilegierten Konto verknüpft war, in den Zugriff auf den Verschlüsselungsschlüssel und verschlüsselte Anmeldedatensätze zu eskalieren. Das Ergebnis ist ein konkretes Bild des Risikos hinter agentischer Automatisierung: Je mehr Systeme ein Agent erreichen kann, desto folgenreicher wird ein Fehler in seiner Berechtigungs- und Ausführungsschicht. Dieser Bericht verfolgt die Angriffskette von exponierten API-Anmeldeinformationen bis hin zu Verschlüsselungsschlüssel-Kompromissen und bietet dann eine gehärtete Konfiguration, die sie an mehreren Punkten unterbricht. Die Wurzel des Vertrauens von n8n Zum Zeitpunkt dieser Forschung hatte n8n seit Januar 2026 48 CVEs erhalten. Mehrere ermöglichten es Angreifern, der Workflowausführungsumgebung zu entkommen und Codeausführung oder Dateisystemzugriff auf dem Host zu erhalten. Sobald ein Angreifer das Dateisystem erreicht, werden zwei Assets zu primären Zielen: , die gespeicherte Anmeldeinformationen in verschlüsselter Form in standardmäßigen SQLite-Bereitstellungen enthält. Die , durch die Umgebung bereitgestellt oder in der n8n-Konfiguration gespeichert, die sie entschlüsselt Zusammen bieten sie Offline-Zugriff auf den Klartextwert jedes in der Datenbank gespeicherten Berechtigungsnachweises. Der Verschlüsselungsschlüssel trägt auch Verantwortlichkeiten jenseits der Credential-Verschlüsselung. In der von uns analysierten Implementierung trägt sie zum Geheimnis bei, das zur Signatur von JSON Web Tokens verwendet wird, und zum Wert, der zur Generierung der Public Instanz ID verwendet wird. Die Konzentration dieser Funktionen in einem Schlüssel macht ihn zum zentralen Vertrauensanker für eine n8n-Instanz. Eine Kompromittierung kann sich auf gespeicherte Anmeldeinformationen, die Integrität von Token, die Authentifizierung von Sitzungen und die Vertraulichkeit jeder verbundenen Integration auswirken. Unsere Analyse identifizierte drei Schwächen in diesem Vertrauensmodell. Drei Schwachstellen in n8ns Schlüsselableitung und Sitzungsauthentifizierung Fehler 1: JWT-Geheimableitung verwirft die Hälfte des Schlüssels Das JWT-Signierungsgeheimnis wird von jedem anderen Zeichen abgeleitet. Unter diesem Ableitungspfad erzeugt ein 32-stelliger Verschlüsselungsschlüssel ein 16-stelliges Signaturgeheimnis. Die Hälfte der Eingabezeichen leistet keinen Beitrag zum abgeleiteten Wert, wodurch die effektive Entropie reduziert wird. Der praktische Schweregrad hängt stark davon ab, wie der ursprüngliche Verschlüsselungsschlüssel generiert wurde. Ein langer, zufällig generierter Schlüssel bleibt schwer wiederherzustellen. Ein kurzer oder menschengedächtniswert ist viel anfälliger für offline-raten. Fehler 2: Sitzungen können für von OIDC bereitgestellte Benutzer gefälscht werden Für Benutzer, die über OpenID Connect bereitgestellt werden, speichert n8n die literale Zeichenfolge im Passwortfeld. Das Session-Token wird mit diesem Passwortwert und dem . Da die Passwortkomponente bekannt ist, kann ein Angreifer, der den Verschlüsselungsschlüssel erhält oder wiederherstellt, die Ableitung reproduzieren und eine Sitzung für einen von OIDC bereitgestellten Benutzer fälschen, ohne das Kennwort des Benutzers zu kennen. Fehler 3: Sitzungen können für ausstehende Benutzer gefälscht werden Eingeladene Benutzer, die die Registrierung nicht abgeschlossen haben, haben einen Null-Passwort-Wert. Während der Sitzungsableitung erzwingt JavaScript diesen Nullwert in einen leeren String. Wie bei OIDC-provisionierten Benutzern wird die Passwortkomponente vorhersehbar. Ein Angreifer mit dem Verschlüsselungsschlüssel kann somit ein gültiges Session-Token für einen anstehenden Nutzer ableiten, ohne ein Passwort zu kennen. Diese Schwächen offenbaren den Verschlüsselungsschlüssel nicht von selbst. Ihre Auswirkungen eme