Automatisierungsplattformen wie n8n verbinden Ticketsysteme, Datenbanken, Cloud-Dienste, Code-Repositories und zunehmend auch KI-Modelle. Ein einzelner Workflow kann deshalb auf mehr sensible Systeme zugreifen als ein normaler Benutzer. Das Praxisproblem beginnt dort, wo Unternehmen den visuellen Workflow-Editor als harmlose Low-Code-Oberfläche behandeln: Wer Abläufe erstellen darf, kann zwar fachlich legitimiert sein, soll aber normalerweise keine Betriebssystembefehle auf dem n8n-Server ausführen.
Eine neu veröffentlichte Analyse zeigt, wie genau diese Grenze in bestimmten n8n-Versionen durchbrochen werden konnte. Die Schwachstelle GHSA-gv7g-jm28-cr3m erlaubt einem authentifizierten Benutzer mit Rechten zum Erstellen oder Ändern von Workflows, die Expression-Sandbox zu umgehen und Befehle mit den Rechten des n8n-Prozesses auszuführen. n8n stuft den Fehler als „High“ ein; GitHub weist einen CVSS-4.0-Wert von 8,7 aus. Für Unternehmen ist das kein anonymer Angriff aus dem Internet, aber ein ernstes Problem der internen Vertrauensgrenze.
Welche Versionen betroffen sind
Laut offiziellem GitHub Security Advisory sind n8n-Versionen vor 2.31.5 sowie Versionen ab 2.32.0 und vor 2.32.1 verwundbar. Behoben ist der Fehler in 2.31.5 und 2.32.1. Das Advisory wurde am 22. Juli 2026 veröffentlicht und am 27. Juli aktualisiert. Zu diesem Zeitpunkt war noch keine CVE-Nummer zugeordnet.
Die wichtigste Voraussetzung darf in der Risikobewertung nicht fehlen: Ein Angreifer benötigt ein gültiges Konto mit Berechtigung zur Workflow-Erstellung oder -Bearbeitung. Eine fremde Person ohne Anmeldung kann den Fehler nach der öffentlichen Beschreibung nicht direkt ausnutzen. Es ist also kein klassischer unauthentifizierter Remote-Code-Execution-Fehler. Relevant wird er durch kompromittierte Editor-Konten, zu breit vergebene Rollen, böswillige Insider oder gemeinsam genutzte Automatisierungsinstanzen.
n8n empfiehlt ein Update auf eine korrigierte Version. Als vorübergehende Maßnahmen nennt das Advisory, den Zugang zur Instanz sowie Bearbeitungsrechte auf vollständig vertrauenswürdige Benutzer zu beschränken. Der Hersteller betont jedoch ausdrücklich, dass diese Workarounds das Risiko nicht vollständig beseitigen.
Wie die Expression-Sandbox umgangen wurde
n8n erlaubt in Workflows JavaScript-ähnliche Expressions, um Daten aus vorherigen Schritten zu lesen und weiterzuverarbeiten. Damit solche Ausdrücke nicht beliebig auf die Node.js-Laufzeit zugreifen, analysiert und verändert eine Komponente den Syntaxbaum, den sogenannten Abstract Syntax Tree. Freie Bezeichner sollen auf einen kontrollierten Datenkontext umgeleitet werden, statt auf globale Objekte des Prozesses zu zeigen.
Nach der am 27. Juli veröffentlichten Analyse von Security Joes bestand die neue Schwachstelle aus zwei zusammenwirkenden Lücken. Erstens behandelte der Rewriter kompakte Arrow Functions nicht vollständig. Ein Bezeichner im kurzen Funktionskörper konnte dadurch außerhalb der vorgesehenen Datenumleitung aufgelöst werden. Zweitens konzentrierte sich eine Schutzprüfung auf statisch erkennbare Eigenschaftsnamen. Ein dynamischer Zugriff über die JavaScript-Reflektions-API konnte diese Annahme umgehen.
Die Kombination ermöglichte es den Forschern nach eigener Darstellung, den realen Node.js-Prozess zu erreichen, ein integriertes Modul zu laden und schließlich einen Betriebssystemprozess zu starten. Der veröffentlichte Patch ergänzt eine gezielte Behandlung von Arrow-Function-Ausdrücken. The Hacker News verglich die öffentlichen Quelldateien der Versionen 2.31.4 und 2.31.5 und bestätigte die sichtbare Änderung am Rewriter, weist aber zurecht darauf hin, dass damit nicht automatisch die gesamte beschriebene Angriffskette unabhängig reproduziert ist.
Warum der Host-Zugriff so weitreichend sein kann
Der ausgeführte Befehl läuft mit den Rechten des n8n-Prozesses. Der tatsächliche Schaden hängt deshalb stark von der Architektur ab. Eine sauber isolierte Instanz mit restriktivem Service-Konto, minimalen Netzrechten und getrenntem Credential-Backend begrenzt den Effekt. Eine zentrale Automatisierungsplattform mit weitreichenden Cloud-Tokens, Datenbankzugängen und internem Netzwerkzugriff vergrößert ihn erheblich.
Security Joes nennt insbesondere den möglichen Zugriff auf den N8N_ENCRYPTION_KEY. Gelangt ein Angreifer an diesen Schlüssel und die zugehörigen gespeicherten Daten, können in n8n hinterlegte Zugangsdaten gefährdet sein. Hinzu kommen alle Ziele, die vom Host erreichbar sind: interne APIs, Datenbanken, CI/CD-Systeme, Cloud-Endpunkte oder Modell-Gateways. Bei KI- und Agenten-Workflows können außerdem API-Schlüssel, Vektordatenbanken, Tool-Zugänge und MCP-nahe Dienste betroffen sein. Das ist keine besondere „KI-Schwachstelle“, sondern die Folge davon, dass Agenten und Automatisierungen viele privilegierte Verbindungen an einem Ort bündeln.
Branchenkontext: Sandbox-Patches brauchen Negativtests
Der Fund ist auch deshalb relevant, weil Security Joes die Lücke bei der Prüfung eines früheren n8n-Patches entdeckte. CVE-2026-27577 betraf ebenfalls die Expression-Sandbox und war im Februar korrigiert worden. Nach Angaben der Forscher war keine der beiden jetzt kombinierten Bedingungen allein ausreichend; zugleich seien beide nicht durch Tests abgedeckt gewesen.
Das verweist auf ein allgemeines DevSecOps-Problem. Eine Sandbox ist kein einzelner Filter, sondern eine Sammlung von Annahmen über Syntax, Laufzeit, Objektzugriffe und Seiteneffekte. Ein Patch, der nur den bekannten Beispielpfad blockiert, kann semantisch gleichwertige Varianten übersehen. Anbieter und Betreiber brauchen daher Regressionstests mit unterschiedlichen Sprachkonstrukten, dynamischen Zugriffen und verschachtelten Ausdrücken. Besonders wichtig sind Negativtests: Nicht nur „funktioniert der erlaubte Workflow?“, sondern „bleibt jeder unerlaubte Pfad wirklich unerreichbar?“
Was Unternehmen jetzt konkret tun sollten
Erstens sollten Betreiber die installierte n8n-Version inventarisieren und auf 2.31.5, 2.32.1 oder neuer aktualisieren. Dass keine CVE-Nummer vorliegt, ist kein Grund, den Patch in üblichen Schwachstellenprozessen zu übersehen; die GHSA-Kennung gehört in Scanner, Ausnahmelisten und Change-Tickets.
Zweitens sollten Workflow-Rechte nach dem Least-Privilege-Prinzip überprüft werden. Fachliche Nutzer brauchen nicht automatisch globale Editor-Rechte. Produktionsinstanzen sollten Entwicklung, Freigabe und Ausführung trennen. Vier-Augen-Freigaben für Workflows mit privilegierten Credentials reduzieren sowohl Fehlkonfigurationen als auch Missbrauch.
Drittens lohnt sich eine gezielte Nachsuche. Zu prüfen sind kürzlich erstellte oder geänderte Workflows mit ungewöhnlichen Arrow Functions oder verschleiertem JavaScript. Auf Host-Ebene sind Shells, PowerShell, curl oder wget als Kindprozesse von n8n beziehungsweise Node.js verdächtig. Container- und EDR-Telemetrie sollte solche Prozessketten sichtbar machen.
Viertens sollten Teams die Folgen eines möglichen Zugriffs bewerten. Bei verdächtiger Workflow-Ausführung reicht das Update allein nicht: Zugangsdaten, Tokens und gegebenenfalls der n8n-Verschlüsselungsschlüssel müssen nach einem abgestuften Incident-Response-Plan rotiert werden. Egress-Regeln, getrennte Secrets-Dienste, kurzlebige Tokens und Netzwerksegmentierung senken den künftigen Blast Radius.
Risiken und Grenzen der öffentlichen Informationen
Security Joes hatte zum Zeitpunkt des Berichts keine Ausnutzung in freier Wildbahn beobachtet. Auch das öffentliche Advisory nennt keine aktive Angriffskampagne. Die technische Kette setzt vorhandene Editor-Rechte voraus, und ihr Ergebnis hängt von Prozessrechten, Deployment-Modell und erreichbaren Diensten ab. Unternehmen sollten deshalb weder Entwarnung geben noch pauschal von einer vollständigen Serverübernahme jeder n8n-Instanz sprechen.
Offen bleibt außerdem, ob n8n Cloud betroffen war; das Advisory macht hierzu keine Aussage. Für selbst gehostete Installationen sind die Versionsgrenzen dagegen klar. Die öffentlich sichtbare Codeänderung stützt den beschriebenen Arrow-Function-Fehler, während Details der vollständigen Forschungskette bislang vor allem aus dem Bericht von Security Joes und der darauf basierenden Berichterstattung stammen.
Fazit
Der n8n-Sandbox-Escape zeigt, warum Low-Code- und Agentenplattformen wie privilegierte Laufzeitumgebungen behandelt werden müssen. Ein Workflow-Editor ist keine gewöhnliche Formularoberfläche, wenn dahinter Betriebssystemzugriff, Secrets und Verbindungen in produktive Netze liegen.
Die unmittelbare Maßnahme ist eindeutig: aktualisieren, Editor-Rechte begrenzen und verdächtige Prozessketten prüfen. Strategisch wichtiger ist die Architekturfrage. Automatisierung darf viele Systeme verbinden, aber ein Fehler in ihrer Ausdruckssprache sollte nicht automatisch Zugriff auf alle verbundenen Identitäten und Daten eröffnen. Isolation, kurzlebige Credentials und überprüfbare Freigaben gehören deshalb zur Plattform – nicht erst zur Reaktion auf den nächsten Sandbox-Patch.
Quellen
- GitHub Security Advisory, „n8n: Expression sandbox escape via arrow-function bodies enabling command execution“, GHSA-gv7g-jm28-cr3m: https://github.com/advisories/GHSA-gv7g-jm28-cr3m
- The Hacker News, „n8n Sandbox Escape Lets Workflow Editors Run OS Commands as the n8n Process“, 27. Juli 2026: https://thehackernews.com/2026/07/n8n-sandbox-escape-lets-workflow.html
- Security Joes, „Breaking the Sandbox Again: Bypassing n8n's CVE-2026-27577 Patch“, 27. Juli 2026, technische Analyse; zentrale Details in der Berichterstattung von The Hacker News wiedergegeben.
