Stellen Sie sich vor, Ihre gesamte IT-Automatisierung läuft über eine zentrale Plattform: Datenintegration, API-Verbindungen, interne Workflows, Benachrichtigungen. n8n hat sich in den letzten Jahren zu genau einem solchen Herzstück in tausenden Unternehmensinfrastrukturen entwickelt. Umso alarmierender ist, was Sicherheitsforscher in dieser Woche veröffentlicht haben: Zwei kritische Schwachstellen mit einem CVSS-Score von jeweils 9.4 ermöglichen es Angreifern, auf verwundbare n8n-Instanzen vollständig zuzugreifen – und damit potenziell auf alle angebundenen Systeme.

Was ist n8n – und warum ist es so attraktiv für Angreifer?

n8n (ausgesprochen: „n-acht-n") ist eine Open-Source-Plattform für Workflow-Automatisierung, die häufig als selbst gehostete Alternative zu Zapier oder Make eingesetzt wird. Mit über 400 integrierten Konnektoren verbindet n8n alles: Datenbanken, CRM-Systeme, Cloud-Dienste, interne APIs und externe Webservices. Wer n8n in seiner Infrastruktur betreibt, hat dort typischerweise hochsensible API-Schlüssel, Zugangsdaten und Verbindungsparameter für sämtliche angebundene Systeme hinterlegt.

Genau das macht n8n zu einem lohnenden Ziel. Ein kompromittierter n8n-Server ist kein isoliertes Problem – er ist ein Schlüssel zum gesamten digitalen Ökosystem eines Unternehmens. Angreifer müssen nicht mehr einzelne Systeme hacken, wenn sie durch eine einzige Schwachstelle Zugriff auf die Automatisierungsschicht erhalten.

CVE-2026-27495: Sandbox Escape via Prototype Climbing (CVSS 9.4)

Die erste Schwachstelle betrifft den JavaScript Task Runner von n8n. Dieser ist dafür zuständig, benutzerdefinierte JavaScript-Code-Blöcke innerhalb von Workflows sicher auszuführen – isoliert vom restlichen System. Doch genau diese Isolation versagt.

Durch einen sogenannten Prototype-Climbing-Angriff gelingt es einem authentifizierten Nutzer, die Sandbox-Grenzen zu überwinden. Konkret: JavaScript-Objekte erben in der Sprache über die Prototyp-Kette. Wenn diese Kette nicht ausreichend abgeschnitten wird, kann ein Angreifer von einem harmlosen Objekt schrittweise bis zum nativen Function-Konstruktor des Node.js-Hosts hochklettern. Von dort aus lassen sich beliebige Systembefehle ausführen – Remote Code Execution (RCE).

In der Standardkonfiguration (Internal Task Runner) läuft der Code als Subprozess der Hauptanwendung. Ein erfolgreicher Exploit macht den Angreifer zum Nutzer, unter dem n8n läuft – und verschafft ihm damit Zugriff auf alle gespeicherten Credentials, Workflow-Daten und angebundene Dienste. In der External-Task-Runner-Konfiguration ist der Blast Radius etwas kleiner, aber der Worker hat dennoch Zugriff auf alle gerade verarbeiteten Daten.

Betroffene Versionen: Alle n8n-Versionen vor 1.123.22, 2.9.3 und 2.10.1.

CVE-2026-27497: AlaSQL-Injection im Merge Node (CVSS 9.4)

Die zweite Schwachstelle ist technisch ebenso elegant wie gefährlich. Der Merge Node in n8n bietet einen SQL-Modus, der auf der eingebetteten JavaScript-SQL-Engine AlaSQL basiert. Diese Engine – ursprünglich für client-seitige Datenbankabfragen konzipiert – unterstützt eine Besonderheit: Innerhalb von SQL-Query-Strings lassen sich JavaScript-Funktionen definieren und ausführen.

Das bedeutet: Wer SQL-Eingaben in den Merge Node einschleusen kann, kann damit die n8n-Sandbox vollständig umgehen und beliebigen Code auf dem Host ausführen – oder beliebige Dateien auf dem Server schreiben. Der technische Angriffspfad führt direkt an Sandboxing-Mechanismen vorbei, weil AlaSQL nie dafür gedacht war, als Sicherheitsgrenze zu fungieren.

Für Unternehmen, die n8n für Datentransformationen oder ETL-ähnliche Workflows nutzen, ist dies besonders kritisch: Wenn Eingabedaten aus externen Quellen (APIs, Formulare, E-Mails) ungeprüft in Merge-Node-Abfragen fließen, ist ein Angriff über manipulierte Daten möglich.

Welche Versionen sind betroffen?

Beide Schwachstellen betreffen alle n8n-Versionen bis einschließlich:

  • Version-1-Branch: bis 1.123.21 (inklusive)
  • Version-2-Branch: bis 2.9.2 und 2.10.0 (inklusive)

Gepatcht sind die Versionen 1.123.22, 2.9.3 und 2.10.1. Diese Updates sollten sofort eingespielt werden.

Sofortmaßnahmen und Mitigationen

Wer n8n betreibt, sollte jetzt folgende Schritte unternehmen:

1. Sofort patchen

Das Update auf die gepatchten Versionen ist die wichtigste Maßnahme. Bei selbst gehosteten Instanzen:

# Docker-Update (Beispiel)
docker pull n8nio/n8n:2.10.1
docker-compose up -d

# npm-Installation
npm update -g n8n

Prüfen Sie Ihre aktuelle Version mit n8n --version oder im Admin-Interface unter Settings → About.

2. Temporäre Mitigation für CVE-2026-27495

Falls ein sofortiges Update nicht möglich ist, können Sie den externen Task Runner aktivieren, um den Blast Radius zu begrenzen:

N8N_RUNNERS_MODE=external

Dies isoliert den Code-Runner als separaten Prozess. Ein erfolgreicher Exploit kompromittiert dann nur diesen Worker – nicht die gesamte n8n-Instanz.

3. Temporäre Mitigation für CVE-2026-27497

Den Merge Node deaktivieren, bis der Patch eingespielt ist:

NODES_EXCLUDE=n8n-nodes-base.merge

Vorsicht: Dies deaktiviert die Merge-Funktionalität komplett. Prüfen Sie vorher, welche Workflows davon abhängen.

4. Credential-Audit durchführen

Wenn Sie nicht sicher sind, ob Ihre Instanz bereits kompromittiert wurde, führen Sie einen vollständigen Credential-Audit durch. Überprüfen Sie die Zugriffslogs auf ungewöhnliche Aktivitäten und rotieren Sie alle in n8n hinterlegten API-Schlüssel und Passwörter – insbesondere für kritische Systeme wie CRM, ERP und Datenbanken.

5. Netzwerksegmentierung prüfen

n8n-Instanzen sollten niemals direkt aus dem Internet erreichbar sein. Wenn Ihre n8n-Instanz öffentlich zugänglich ist, schränken Sie den Zugriff umgehend auf authentifizierte, autorisierte Nutzer ein – idealerweise über VPN oder IP-Whitelisting.

Der größere Kontext: Automatisierungsplattformen als Angriffsziel

Die n8n-Schwachstellen sind kein Einzelfall. Sie illustrieren einen wichtigen Trend: Integrationsplattformen und Automatisierungswerkzeuge werden zunehmend als strategische Angriffsziele betrachtet. Warum einzelne Systeme mühsam kompromittieren, wenn die Automatisierungsschicht Zugriff auf alle gleichzeitig verspricht?

Ähnliche Muster sehen wir bei CI/CD-Pipelines (GitHub Actions, Jenkins), bei RPA-Plattformen (UiPath, Automation Anywhere) und – wie im März dieses Jahres – bei Backup-Software wie Veeam. All diese Systeme haben eines gemeinsam: Sie verfügen über privilegierte Zugänge zu vielen anderen Systemen und werden in der Sicherheitsstrategie oft stiefmütterlich behandelt.

Das ganzheitliche Informationssicherheitskonzept eines Unternehmens muss diese Systeme explizit einschließen: in Patch-Management-Prozessen, in der Netzwerksegmentierung und in Schwachstellenscans.

Einordnung: Warum CVSS 9.4 Soforthandeln erfordert

CVSS 9.4 ist eine der höchsten Einstufungen im Common Vulnerability Scoring System. Die Kriterien, die zu diesem Score geführt haben, sind eindeutig: Geringe Angriffskomplexität, kein physischer Zugang erforderlich, weitreichende Auswirkungen auf Vertraulichkeit, Integrität und Verfügbarkeit der betroffenen Systeme.

In der Praxis bedeutet das: Ein entschlossener Angreifer mit gültigen n8n-Zugangsdaten – oder mit Zugriff auf einen kompromittierten Account – kann innerhalb von Minuten vollständige Kontrolle über den Server übernehmen. Bei Cloud-Deployments, wo n8n oft mit weitreichenden IAM-Rechten läuft, kann das eine gesamte Cloud-Umgebung gefährden.

Die historische Erfahrung mit ähnlich kritischen Schwachstellen zeigt: Proof-of-Concept-Exploits erscheinen typischerweise innerhalb von 24–72 Stunden nach Veröffentlichung eines CVE in öffentlichen Repositories. Wer nicht sofort patcht, riskiert aktive Ausnutzung.

Was tun, wenn die eigene Instanz bereits kompromittiert sein könnte?

Falls Sie n8n seit mehreren Wochen in einer verwundeten Version betreiben und öffentlich zugänglich hatten, sollten Sie von einer möglichen Kompromittierung ausgehen. Folgende Schritte sind dann angebracht:

Sofortmaßnahmen: Instanz vom Netz nehmen, alle dort gespeicherten Credentials als kompromittiert betrachten und sofort rotieren. Logs sichern, bevor sie überschrieben werden. Den Vorfall dem CISO und – bei NIS2-Relevanz – dem BSI melden.

Forensik: Prüfen Sie, ob ungewöhnliche Prozesse auf dem Host gestartet wurden, ob neue Benutzer angelegt wurden, ob Cron-Jobs oder Systemdienste verändert wurden, und ob unbekannte Netzwerkverbindungen aufgebaut wurden.

Bei Bedarf unterstützt pleXtec bei der Sicherheitsanalyse und Incident Response sowie bei der sicheren Neuaufstellung Ihrer Automatisierungsinfrastruktur. Sprechen Sie uns über unser Kontaktformular an.

Fazit: Automatisierung braucht Sicherheitskultur

n8n ist ein mächtiges Werkzeug – und genau deshalb muss seine Absicherung ernst genommen werden. Die aktuellen Schwachstellen CVE-2026-27495 und CVE-2026-27497 zeigen exemplarisch, was passiert, wenn Sicherheitsgrenzen in komplexen Systemen nicht rigoros durchgesetzt werden: JavaScript-Sandbox-Escapes durch Prototype Climbing, SQL-Engines mit unbeabsichtigter Code-Execution-Fähigkeit.

Das Update steht bereit. Der Aufwand ist gering. Die Konsequenzen eines Exploits könnten erheblich sein. Patchen Sie jetzt.