Im Februar 2026 wurde eine kritische Sicherheitslücke in n8n, der weit verbreiteten Open-Source-Plattform zur Workflow-Automatisierung, öffentlich bekannt gegeben, die einen Sandbox-Ausbruch ermöglicht. Diese unter der Kennung CVE-2026-25049 erfasste Schwachstelle ermöglicht es authentifizierten Benutzern, die Sandbox für die Auswertungsauswertung zu umgehen und beliebige Systembefehle auf dem Host-Server auszuführen, wodurch eine vollständige Remote-Codeausführung mit einem CVSS v3.1-Wert von 9,9 erreicht wird.
Im Rahmen des OPSWAT Fellowship Program haben unsere Stipendiaten eine umfassende technische Analyse von CVE-2026-25049 durchgeführt und dabei die Ursache, den Ausnutzungsmechanismus sowie die Auswirkungen auf Unternehmen untersucht.
Dieser Blogbeitrag bietet einen detaillierten Überblick über die Sicherheitslücke – von der Architektur der Ausdrucksverarbeitung bei n8n und ihren mehrschichtigen Sicherheitskontrollen bis hin zu der genauen Technik, mit der alle fünf Verteidigungsebenen gleichzeitig umgangen werden.
CVE-2026-25049 ist eine kritische Sicherheitslücke in n8n, die einen Ausbruch aus der Sandbox durch einen Ausdruck ermöglicht und unter CWE-913 klassifiziert ist: Unsachgemäße Kontrolle dynamisch verwalteter Code-Ressourcen. Die Schwachstelle betrifft alle n8n-Versionen vor 1.123.17 sowie die Versionen 2.0.0 bis 2.5.1 und wurde in den Versionen 1.123.17 und 2.5.2 behoben. Sie ermöglicht es authentifizierten Benutzern mit Berechtigungen zur Erstellung von Workflows, bösartige JavaScript-Ausdrücke zu erstellen, die die Ausdrucks-Sandbox der Plattform umgehen und letztendlich die Ausführung beliebiger Befehle auf dem Host-Server ermöglichen.
Die Sicherheitslücke ist besonders gravierend, da n8n in der Regel eine privilegierte Position innerhalb der Infrastruktur eines Unternehmens einnimmt. Als Dreh- und Angelpunkt für die Workflow-Automatisierung verfügt n8n in der Regel über direkten Zugriff auf interne APIs, Datenbanken, Speicherstellen für Anmeldedaten und Dienste von Drittanbietern. Eine kompromittierte n8n-Instanz setzt nicht nur den Automatisierungsserver einer Gefahr aus – sie bietet auch einen Einstiegspunkt in jedes verbundene System, wodurch sich der Umfang der möglichen Schäden drastisch vergrößert.
CVE-2026-25049 ist keine eigenständige Entdeckung, sondern eine Umgehung des Patches für CVE-2025-68613, einen früheren Sandbox-Escape im Ausdrucksauswerter von n8n. Trotz der Implementierung mehrschichtiger Abwehrmaßnahmen nach der ursprünglichen Sicherheitslücke ermöglichte eine grundlegende Lücke in der Art und Weise, wie der Sanitizer JavaScript-AST-Knotentypen (Abstract Syntax Tree) verarbeitet, dass die ursprüngliche Angriffsklasse über einen anderen syntaktischen Vektor wieder auftauchte. Dieses Muster – bei dem ein Patch die spezifische Exploit-Technik und nicht die zugrunde liegende Designschwäche behebt – verdeutlicht die anhaltende Herausforderung bei der Sicherung dynamischer Codeauswertungsumgebungen.
Die Sicherheitslücke wurde am 4. Februar 2026 zusammen mit zehn weiteren Sicherheitshinweisen für n8n bekannt gegeben und von mehreren Sicherheitsforschungsteams unabhängig voneinander analysiert.
Über n8n
n8n ist eine Open-Source-Plattform zur Workflow-Automatisierung, die es Unternehmen ermöglicht, Systeme zu vernetzen, Prozesse zu automatisieren und Integrationen zwischen Hunderten von Diensten zu erstellen. Dank seiner breiten Akzeptanz und über 1.300 verfügbaren Integrationen hat sich n8n zu einem der beliebtesten Tools seiner Kategorie entwickelt und wird von Entwicklungsteams und Unternehmen genutzt, um alles von internen Tools bis hin zu geschäftskritischen Datenpipelines zu automatisieren.
Die Plattform unterstützt sowohl selbst gehostete als auch Cloud-Bereitstellungen und bietet neben direkter JavaScript-Unterstützung für benutzerdefinierte Logik einen visuellen Workflow-Builder. Die Architektur von n8n ist knotenbasiert: Workflows bestehen aus miteinander verbundenen Knoten, die Daten im JSON-Format zwischen Triggern, Aktionen und Funktionsschritten austauschen. Die Ausführung kann im manuellen Modus zum Testen oder im Produktionsmodus für den Live-Einsatz erfolgen. Diese Architektur, kombiniert mit nativer Unterstützung für JavaScript-Ausdrücke und Zugriff auf interne APIs und Anmeldedaten-Speicher, macht n8n zu einem leistungsstarken Automatisierungstool – aber auch zu einem attraktiven Ziel, wenn Schwachstellen auftreten.
Technischer Hintergrund
Abstrakte Syntaxbäume
Ein abstrakter Syntaxbaum (AST) ist eine hierarchische Darstellung des von einem Parser erzeugten Quellcodes. Anstatt den Code als flache Zeichenkette zu behandeln, zerlegt ein AST ihn in strukturierte Knoten, die seine syntaktischen Elemente darstellen – Variablendeklarationen, Funktionsausdrücke, Member-Ausdrücke, Bezeichner und Literale.
Das Verständnis der AST-Knotentypen ist für diese Analyse von entscheidender Bedeutung, da die Sicherheitskontrollen von n8n auf AST-Ebene ablaufen. Die Sanitizer überprüfen bestimmte Knotentypen, um gefährliche Muster zu erkennen und zu blockieren. Die Sicherheitslücke nutzt die Tatsache aus, dass dieselbe semantische Operation – der Zugriff auf die Eigenschaft eines Objekts – je nach verwendeter JavaScript-Syntax völlig unterschiedliche AST-Knotentypen erzeugen kann.
Beispielsweise erzeugt der Ausdruck `obj.constructor ` einen `MemberExpression` -Knoten, während `const { constructor } = obj ` eine `VariableDeclaration` erzeugt , die ein `ObjectPattern` mit einem `Property`-Knoten enthält. Beide extrahieren dieselbe Eigenschaft, doch die AST-Strukturen unterscheiden sich grundlegend – und die Sanitizer von n8n prüfen nur das erste Muster.
n8n: Auswertung von Ausdrücken und Sicherheitsarchitektur
Die Architektur von n8n ist in fünf Schichten gegliedert: Frontend, CLI, Core, Workflow und Nodes. Die Workflow-Schicht ist für die Auswertung von Ausdrücken zuständig, was für diese Sicherheitslücke von Bedeutung ist.
Mit n8n können Benutzer JavaScript-Ausdrücke in die Parameter von Workflow-Knoten einbetten, um Daten dynamisch zu bearbeiten. Diese Ausdrücke werden serverseitig mithilfe einer Bibliothek namens „Tournament“ ausgewertet, die die Ausdrücke vor der Ausführung in einen AST (Abstrakter Syntaxbaum) parst. Sanitization-Hooks werden direkt in den Erstellungsprozess von Tournament eingebunden und führen während der AST-Erstellung Prüfungen durch, um gefährliche Muster abzufangen, bevor Code ausgeführt wird.
Da diese Ausdrücke innerhalb desselben Node.js-Prozesses wie der n8n-Server ausgeführt werden, verfügt die Plattform über fünf verschiedene Sicherheitsebenen, die verhindern sollen, dass nicht vertrauenswürdiger Code die Sandbox umgeht.
Ebene 1 – Überschreiben des globalen Kontexts
Bevor ein Ausdruck ausgewertet wird, erstellt n8n einen eingeschränkten Ausführungskontext, indem gefährliche globale Objekte und Funktionen überschrieben werden. Eigenschaften wie `document`, `window`, `globalThis`, `eval`, `setTimeout`, `setInterval` und `Function` werden durch leere Objekte ersetzt, wodurch der direkte Zugriff auf diese Funktionen verhindert wird.
Dieser Ansatz weist eine inhärente Einschränkung auf: Wenn es einem Angreifer gelingt, den eingeschränkten Kontext zu umgehen und das eigentliche globale Prozessobjekt zu erreichen, verlieren die überschriebenen Eigenschaften ihre Bedeutung.
Ebene 2 – Überprüfung anhand regulärer Ausdrücke
Bevor der Ausdruck den Auswerter erreicht, führt n8n eine Überprüfung anhand regulärer Ausdrücke auf die rohe Ausdruckszeichenfolge durch, um den Zugriff auf die Konstruktor-Eigenschaft zu blockieren – ein gängiger Angriffsvektor, um an den Function-Konstruktor zu gelangen und Codeausführung zu erreichen.
Der reguläre Ausdruck /\.\s*constructor/gm erkennt den Zugriff auf .constructor mittels Punktnotation. Diese Überprüfung ist jedoch grundsätzlich begrenzt, da JavaScript mehrere syntaktische Wege für den Zugriff auf dieselbe Eigenschaft bietet, von denen nicht alle die Punktnotation verwenden.
Ebene 3 – AST-Laufzeit-Sanitizer – PrototypeSanitizer
Die ausgefeilteste Schutzmaßnahme greift während der Erstellung des AST. Der PrototypeSanitizer-Hook durchläuft den AST und überprüft MemberExpression-Knoten, um festzustellen, ob die aufgerufene Eigenschaft auf einer Sperrliste unsicherer Objekteigenschaften steht – darunter constructor, __proto__, prototype, mainModule und binding.
Der Sanitizer behandelt drei Fälle: die Punktnotation (obj.prop), bei der der Bezeichnername überprüft wird, die statische Klammernotation (obj['prop']), bei der der Wert des String-Literals überprüft wird, sowie dynamische Ausdrücke, die in eine Laufzeit-Sanitizer-Funktion eingebettet sind. Wie in Abbildung 10 dargestellt, werden nur MemberExpression-Knoten überprüft – Destrukturierungsmuster werden nicht durchlaufen.
Ebene 4 – AST-Laufzeit-Sanitizer-FunktionThisSanitizer
Der FunctionThisSanitizer wurde als direkter Patch für CVE-2025-68613 hinzugefügt. Er fängt sofort aufgerufene Funktionsausdrücke (IIFEs) ab und schreibt sie so um, dass „this“ an ein leeres Objekt gebunden wird. Dadurch wird die im ursprünglichen Exploit verwendete Technik verhindert, bei der (function(){ return this })() das globale Prozessobjekt über die ungebundene „this“-Referenz preisgab.
Entscheidend ist, dass dieser Sanitizer nur „FunctionExpression“-Knoten verarbeitet. Er bricht den Ablauf bei jedem Aufgerufenen, der kein „FunctionExpression“-Knoten ist – einschließlich Pfeilfunktionen –, ausdrücklich vorzeitig ab.
Gefährliche Eigenschaften wie „eval“, „Function“ und „process.mainModule“ werden im Ausführungskontext entfernt oder überschrieben, wodurch der direkte Zugriff auf Codeausführungsprimitive verhindert wird, selbst wenn frühere Ebenen umgangen werden.
Schwachstellenanalyse
Grundursache
Die eigentliche Ursache von CVE-2026-25049 liegt in einer gemeinsamen Annahme aller fünf Sicherheitsebenen: Jede Ebene ging davon aus, dass der Zugriff auf Eigenschaften entweder über die Punktnotation (obj.constructor) oder die Klammernotation (obj['constructor']) erfolgen würde. Keine der Ebenen berücksichtigte die Destrukturierungssyntax von JavaScript.
Die JavaScript-Destrukturierung ermöglicht es, Eigenschaften aus Objekten mithilfe einer grundlegend anderen AST-Struktur zu extrahieren:
// Traditional access - produces MemberExpression node
obj.constructor; // Blocked by regex, AST sanitizer, and runtime checks
// Destructuring - produces ObjectPattern → Property node
const { constructor } = obj; // Not checked by any layer
Obwohl beide Muster zum gleichen Ergebnis führen, erzeugen sie völlig unterschiedliche AST-Darstellungen. Der PrototypeSanitizer überprüft nur MemberExpression-Knoten, und der reguläre Ausdruck findet nur Übereinstimmungen mit .constructor-Mustern. Destrukturierungszuweisungen erzeugen VariableDeclaration- → ObjectPattern- → Property-Knoten, die von keinem der Sanitizer durchlaufen werden.
Hinzu kommt die Art und Weise, wie n8n mit Pfeilfunktionen umgeht. Der FunctionThisSanitizer fängt nur FunctionExpression-Knoten ab und schreibt sie so um, dass „this“ an einen sicheren Kontext gebunden wird. Pfeilfunktionen erzeugen ArrowFunctionExpression-AST-Knoten, die der Sanitizer nicht verarbeitet. Da Pfeilfunktionen „this“ aus ihrem umgebenden Geltungsbereich erben (lexikalisches „this“), ermöglichen sie den Zugriff auf den nicht bereinigten globalen Kontext.
Zusammen führen diese beiden Versäumnisse zu einer vollständigen Umgehung: Durch die Destrukturierung wird der „Function“-Konstruktor extrahiert, ohne dass dabei Überprüfungen des Zugriffs auf Eigenschaften ausgelöst werden, und Pfeilfunktionen bieten einen Ausführungskontext, den der „FunctionThisSanitizer“ nicht abfängt.
Ausbeutung
Der Exploit nutzt beide Schwachstellen aus, um alle Sicherheitsebenen gleichzeitig zu durchbrechen. Unsere Kollegen haben den folgenden Ausnutzungsweg nachverfolgt:
Schritt 1 – Eingabe der Pfeilfunktion. Die Nutzlast beginnt mit einer Pfeilfunktion, die in einen sofort aufgerufenen Funktionsausdruck (IIFE) eingeschlossen ist:
={{(() => {
// Pfeilfunktion – umgeht den FunctionThisSanitizer
...
})()}}
Der `FunctionThisSanitizer` prüft, ob der Aufgerufene ein `FunctionExpression` ist; da es sich um einen `ArrowFunctionExpression` handelt, kehrt der Sanitizer vorzeitig zurück, ohne den Aufruf umzuschreiben. Die Pfeilfunktion wird mit uneingeschränktem Zugriff auf den tatsächlichen globalen Kontext ausgeführt.
Schritt 2 – Umgehung der Destrukturierung. Innerhalb der Pfeilfunktion extrahiert die Destrukturierung den `Function`-Konstruktor aus einer Instanz der Pfeilfunktion:
const { constructor } = () => {};
Da es sich hierbei um eine Destrukturierungszuweisung handelt, enthält der AST einen „ObjectPattern“-Knoten anstelle eines „MemberExpression“-Knotens. Die Regex-Prüfung erkennt kein „.constructor“-Muster, und der „PrototypeSanitizer“ überprüft den Eigenschaftsnamen nicht. Der Angreifer verfügt nun über eine Referenz auf den „Function“-Konstruktor.
Schritt 3 – Dynamische Codeausführung. Mit dem erhaltenen Funktionskonstruktor erstellt der Angreifer beliebigen Code und führt ihn aus:
return constructor(
'return process.mainModule.require("child_process").execSync("whoami").toString()',
)();
Die dynamisch erstellte Funktion läuft außerhalb des Sandbox-Kontexts und verfügt über uneingeschränkten Zugriff auf das Node.js-Prozessobjekt, wodurch die Ausführung beliebiger Systembefehle auf dem Host ermöglicht wird.
Konzeptnachweis
Um die praktischen Auswirkungen dieser Sicherheitslücke zu veranschaulichen, haben unsere Mitarbeiter den Exploit in einer kontrollierten Laborumgebung nachgestellt. Das Angriffsszenario umfasst das Hosten einer anfälligen n8n-Instanz und den Import eines Workflows, der die schädliche Nutzlast in einem Knotenparameter enthält – wobei gezielt der Knoten „Edit Fields“ ins Visier genommen wird, der die Auswertung von Ausdrücken zulässt.
Sobald der Workflow ausgelöst wird, umgeht die Schadlast alle fünf Sicherheitsfilter und führt auf dem Host-Server eine Reverse-Shell aus, wodurch der Angreifer wieder uneingeschränkte Befehlsausführungsrechte erhält.
Webhook-Eskalation zu unauthentifiziertem RCE
Die Schwere dieser Sicherheitslücke nimmt in Verbindung mit der Webhook-Funktionalität von n8n erheblich zu. n8n ermöglicht es, dass Workflows HTTP-Endpunkte als Webhooks mit konfigurierbaren Authentifizierungsoptionen bereitstellen, darunter Bearer-Token, Basic-Authentifizierung und – was besonders kritisch ist – gar keine Authentifizierung. Ein Angreifer mit Zugriffsrechten zur Erstellung von Workflows kann einen öffentlichen Webhook mit der Authentifizierungsoption „none“ konfigurieren, die RCE-Payload in einen verbundenen Knoten einbetten und den Workflow aktivieren. Ab diesem Zeitpunkt löst jede HTTP-Anfrage an die Webhook-URL – von jedem beliebigen Ort im Internet aus – die Ausführung beliebiger Befehle auf dem Host-Server aus.
Dieser Eskalationspfad verwandelt CVE-2026-25049 von einer authentifizierten, internen Sicherheitslücke in einen praktisch nicht authentifizierten Angriffsvektor mit internetweiter Reichweite.
Milderung
Das n8n-Team hat die Sicherheitslücke CVE-2026-25049 in den Versionen 1.123.17 und 2.5.2 behoben, indem es eine ordnungsgemäße Typüberprüfung zur Laufzeit in den Sanitisierungsfunktionen implementiert und die AST-Abdeckung erweitert hat, um Destrukturierungsmuster zu verarbeiten. Unternehmen, die betroffene Versionen einsetzen, sollten umgehend ein Upgrade durchführen.
Falls ein sofortiges Upgrade nicht möglich ist, sollten Administratoren die Berechtigungen zum Erstellen und Bearbeiten von Workflows auf ausschließlich vertrauenswürdige Benutzer beschränken und n8n in einer abgesicherten Umgebung mit eingeschränkten Betriebssystemrechten und Netzwerkzugriff bereitstellen.
Angesichts der kritischen Schwere und der einfachen Ausnutzbarkeit – insbesondere in Verbindung mit öffentlichen Webhooks – sollten Unternehmen zudem bestehende Arbeitsabläufe auf verdächtige Ausdrücke überprüfen, auf die Ausführung ungewöhnlicher Systembefehle aus dem n8n-Prozess heraus achten und die Webhook-Konfigurationen auf Endpunkte überprüfen, die ohne Authentifizierung zugänglich sind.
Risikominderung mit OPSWAT
Durch den Einsatz von OPSWAT können Unternehmen anfällige n8n-Komponenten in ihrer Infrastruktur schnell identifizieren und Maßnahmen ergreifen, bevor diese ausgenutzt werden. OPSWAT , eine grundlegende Technologie der MetaDefender®-Plattform, bietet einen umfassenden Überblick über alle Softwarekomponenten, Bibliotheken und Abhängigkeiten, die in der gesamten Unternehmensumgebung zum Einsatz kommen.
Wie in Abbildung 15 dargestellt, hat MetaDefender die Datei „package.json“ gescannt, die die n8n-Abhängigkeit enthält, und CVE-2026-25049 automatisch als „kritisch“ eingestuft, wobei der betroffene Versionsbereich und die empfohlenen behobenen Versionen zur Behebung angezeigt wurden. Dies ermöglicht es Sicherheitsteams, die Schwachstelle in ihrer gesamten Bereitstellungslandschaft schnell zu identifizieren und zu priorisieren.
OPSWAT ist in MetaDefender und MetaDefender Software Chain™ verfügbar und ermöglicht Sicherheitsteams:
- Schwachstellenanfällige Komponenten schnell ausfindig machen – Open-Source-Abhängigkeiten, die von Sicherheitslücken im Zusammenhang mit dem Umgehen von Sandboxen und der Codeausführung betroffen sind, sofort identifizieren, um eine rasche Behebung oder Entfernung zu ermöglichen.
- Sorgen Sie für proaktive Patches und Updates – Überwachen Sie Open-Source-Komponenten kontinuierlich, um veraltete oder unsichere Pakete zu erkennen, und sorgen Sie so für zeitnahe Updates und eine geringere Sicherheitslücke.
- Einhaltung von Vorschriften und Berichtspflichten – Erfüllen Sie die gesetzlichen Anforderungen, da Rahmenbedingungen zunehmend Transparenz in Software-Lieferketten vorschreiben.
Referenzen
- NVD – CVE-2026-25049
- n8n-Sicherheitshinweis – GHSA-6cqr-8cfr-67f8
- n8n RCE(s): Eine Geschichte in vier Akten – Fatih Çelik
- Ein detaillierter Blick auf CVE-2026-25049 – SecureLayer7
- CVE-2026-25049: Sicherheitslücke durch Ausdruck-Escape, die zu RCE in n8n führt – Endor Labs
- n8n-Sicherheitshinweis – CVE-2025-68613 (GHSA-v98v-ff95-f3cp)
