In der weit verbreiteten Open-Source-Automatisierungsplattform n8n ist mit CVE-2026-25049 eine kritische Schwachstelle bekannt geworden. Die Luecke ermoeglicht Remote Code Execution (RCE) durch einen Sandbox-Bypass und wurde mit einem CVSS-Score von 9,4 bewertet. Angreifer mit gueltigem Konto und Berechtigung zum Erstellen oder Bearbeiten von Workflows koennen unter bestimmten Bedingungen die Kontrolle ueber den gesamten n8n-Server erlangen.
Fehlerhafte JavaScript-Sandbox: Wie es zum Sicherheitsvorfall kam
n8n erlaubt die Verwendung von benutzerdefinierten JavaScript-Ausdruecken in Workflows. Um diese sicher auszufuehren, setzt die Plattform auf eine Sandbox mit AST-basiertem Code-Scanning (Abstract Syntax Tree). Ziel dieser Technik ist es, gefaehrliche Sprachkonstrukte bereits vor der Ausfuehrung zu erkennen und zu blockieren.
Sicherheitsforscher von Pillar Security, Endor Labs und SecureLayer7 konnten jedoch nachweisen, dass diese Implementierung unvollstaendig war. Durch geschickte Umformulierung von Ausdruecken liessen sich die Filterregeln umgehen, sodass Code ausserhalb der vorgesehenen Sandbox ausgefuehrt wurde – inklusive Zugriff auf den globalen Node.js-Kontext und systemnahe Funktionen.
Besonders kritisch: Die neue Schwachstelle CVE-2026-25049 unterlief Schutzmechanismen, die zuvor zur Behebung einer anderen schweren Luecke eingefuehrt worden waren, naemlich CVE-2025-68613 (CVSS 9,9). Trotz des frueheren Patches blieb also ein alternativer Angriffsweg fuer RCE offen.
Angriffsvektoren und Folgen: Von RCE bis zur Kompromittierung von Multi-Tenant-Setups
Fuer eine erfolgreiche Ausnutzung genuegt laut Pillar Security eine normale Benutzerkennung mit dem Recht, Workflows zu erstellen oder zu aendern. In vielen Unternehmen entspricht dies typischen Entwickler-, Integrations- oder Power-User-Rollen.
Gelingt der Sandbox-Bypass, ergeben sich insbesondere folgende Risiken:
1. Remote Code Execution auf Betriebssystemebene. Angreifer koennen Betriebssystem-Befehle ausfuehren, Backdoors installieren, zusätzliche Software nachladen und den kompromittierten Host als Ausgangspunkt fuer weitere Angriffe in der Infrastruktur nutzen. Solche RCE-Schwachstellen zaehlen laut gaengigen Branchenberichten zu den folgenschwersten Incident-Typen, da sie regelmaessig zu Vollkompromittierungen fuehren.
2. Diebstahl von Secrets und Zugriffsdaten. n8n speichert typischerweise API-Keys, OAuth-Tokens, Benutzerkonten und Integrationspasswoerter. Ueber diese Geheimnisse lassen sich angebundene Systeme wie CRM-Plattformen, Datenspeicher oder Cloud-Accounts kompromittieren. Der eigentliche Schaden tritt damit oft ausserhalb des n8n-Servers auf.
3. Zugriff auf Dateisystem und interne Dienste. Mit Serverzugriff koennen Angreifer Dateien auslesen oder in bestimmten Szenarien manipulieren, interne HTTP- oder Datenbank-Services im Cluster ansprechen und damit Segregationseinschraenkungen umgehen. In Multi-Tenant-Umgebungen erhoeht sich damit das Risiko, ueber einen kompromittierten Mandanten hinweg auf andere Kundendaten zuzugreifen.
4. Manipulation von AI-Workflows. n8n wird zunehmend fuer die Orchestrierung von KI- und LLM-Workflows eingesetzt. Ein Angreifer kann hier Prompts abfangen, Antworten von Modellen veraendern, Workflow-Logik unbemerkt anpassen oder Datenstroeme auf eigene Services umlenken – mit unmittelbaren Auswirkungen auf automatisierte Entscheidungen und Ausgaben von KI-Systemen.
Timeline, technische Details und Forschungsergebnisse
Laut Pillar Security wurde das n8n-Team am 21. Dezember 2025 ueber die Schwachstelle informiert. Die Forscher demonstrierten einen funktionierenden Ausbruch aus der Sandbox mit Zugriff auf den globalen Node.js-Objektbaum – ein direkter Weg zur Remote Code Execution.
Bereits zwei Tage spaeter veroeffentlichten die Entwickler ein erstes Sicherheitsupdate. Eine nachgelagerte, vertiefte Analyse zeigte jedoch, dass weiterhin funktional aehnliche Codekonstrukte existierten, die vom AST-Filter nicht erfasst wurden. Somit blieben Angriffsvektoren offen.
Die Luecke wurde schliesslich vollstaendig in n8n Version 2.4.0 geschlossen, die am 12. Januar 2026 erschien. Endor Labs stellte einen leicht nachvollziehbaren Proof-of-Concept-Exploit bereit, der die praktische Ausnutzbarkeit von CVE-2026-25049 belegt.
SecureLayer7 veroeffentlichte technische Details zum Angriffspfad. Demnach gelang es, trotz Sandbox-Beschraenkungen die Ausfuehrung von Code ueber den Function-Konstruktor zu erzwingen – einer Funktion, die in sicheren Umgebungen typischerweise strikt blockiert wird. Nach eigenen Angaben waren ueber 150 Iterationen und Tests mit alternativen Sprachkonstrukten erforderlich, um alle Schutzmassnahmen zu umgehen. Dies unterstreicht, wie herausfordernd die praezise Absicherung von JavaScript-Sandboxes in der Praxis ist.
Empfohlene Schutzmassnahmen und Härtung von n8n-Installationen
Prioritaet: Sicherheitsupdates einspielen
Die n8n-Entwickler empfehlen Betreibern dringend, auf die aktuellen stabilen Versionen 1.123.17 bzw. 2.5.2 zu aktualisieren. Diese Releases enthalten eine ueberarbeitete Sandbox-Implementierung und schliessen CVE-2026-25049 sowie die damit verbundenen Schwachstellen. In produktiven Umgebungen sollte das Update als hoechst prioritaeres Sicherheits-Release betrachtet werden.
Sofortmassnahmen: Annahme einer moeglichen Kompromittierung
Da ein erfolgreicher Angriff kaum Spuren in herkoemmlichen Applikationslogs hinterlassen muss, raten die Forscher zu einem defensiven Vorgehen nach dem Prinzip „Assume Breach“:
1. Verschluesselungsschluessel erneuern. Den fuer Secrets zuständigen Wert N8N_ENCRYPTION_KEY neu setzen und sicher aufbewahren.
2. Saemtliche Credentials rotieren. Alle in n8n gespeicherten Passwoerter, API-Schluessel, Tokens und OAuth-Credentials neu ausstellen und in den Workflows aktualisieren – auch wenn keine direkten Hinweise auf einen Angriff vorliegen.
3. Workflows auf Anomalien pruefen. Bestehende Workflows auf auffaellige JavaScript-Ausdruecke untersuchen, insbesondere solche mit Zugriff auf Systemfunktionen, Dateisystem oder ungewoehnliche Endpunkte.
Wenn Updates nicht sofort moeglich sind
Sollte ein zeitnahes Patchen organisatorisch nicht realisierbar sein, sollten Betreiber zumindest die Angriffsoberflaeche reduzieren:
— Rechte zum Erstellen und Bearbeiten von Workflows auf wenige, vertrauenswuerdige Nutzer beschraenken.
— n8n in einer stark isolierten Umgebung betreiben, mit minimalen Systemrechten, strikten Netzwerk-Filtern und begrenztem Zugriff auf interne Services und Datenbanken.
Weitere geschlossene Schwachstellen: Git-, SQL-, Markdown- und SSH-Komponenten betroffen
Im Zuge der Arbeiten an CVE-2026-25049 wurden in n8n vier weitere Sicherheitsluecken behoben, von denen zwei ebenfalls einen CVSS-Score von 9,4 aufweisen:
— CVE-2026-25053: Befehlseinschleusung in der Git-Node, die die Ausfuehrung beliebiger Kommandos beim Umgang mit Repositories erlaubt.
— CVE-2026-25056: Moeglichkeit zur Schreiboperation beliebiger Dateien ueber SQL Query in der Merge-Node, was die Integritaet des Dateisystems gefaehrdet.
Darueber hinaus wurden zwei weitere, weniger kritische, aber sicherheitsrelevante Probleme geschlossen:
— CVE-2026-25054: Persistentes Cross-Site-Scripting (XSS) im Markdown-Rendering, mit Risiko fuer Angriffe auf Benutzer der Weboberflaeche.
— CVE-2026-25055: Path Traversal in der SSH-Node bei der Verarbeitung hochgeladener Dateien, potenziell nutzbar fuer Zugriffe auf unerwuenschte Verzeichnisse.
Der Vorfall um CVE-2026-25049 zeigt, wie essenziell sauber konzipierte und regelmaessig gepruefte Sandbox-Mechanismen in modernen Automatisierungs- und Low-Code-Plattformen sind. Organisationen, die n8n produktiv einsetzen, sollten nicht nur zeitnah patchen, sondern auch ihr Berechtigungsmodell fuer Workflow-Ersteller ueberarbeiten, Netzwerksegmentierung schaerfen, Anomalie- und Log-Analysen etablieren und eine
