n8n CVE-2026-33696: Prototype-Pollution-Lücke führt zu Remote Code Execution

n8n zählt zu den beliebtesten Open-Source-Werkzeugen für Workflow-Automatisierung und wird in vielen kleinen und mittleren Unternehmen self-hosted per Docker betrieben, oft als günstige Alternative zu Zapier oder Make. Anfang 2026 wurde eine kritische Sicherheitslücke bekannt (CVE-2026-33696), die es einem authentifizierten Nutzer mit Berechtigung zum Erstellen oder Bearbeiten von Workflows erlaubt, über eine Prototype-Pollution-Schwachstelle Remote Code Execution auf dem n8n-Server zu erreichen. Die Lücke wurde inzwischen gepatcht, betrifft aber weiterhin jede Installation, die nicht aktualisiert wurde.

Was ist Prototype Pollution?

Prototype Pollution ist eine JavaScript-spezifische Schwachstellenklasse: Ein Angreifer manipuliert gezielt die Eigenschaften von Object.prototype, dem gemeinsamen Basis-Objekt, von dem alle anderen JavaScript-Objekte erben. Gelingt es, dort einen eigenen Wert zu injizieren, wirkt sich das potenziell auf die gesamte Anwendung aus, da viele interne Funktionen unbewusst auf Eigenschaften zugreifen, die eigentlich vom Prototype geerbt werden sollten. In Kombination mit einer Anwendung, die diese Werte später für sicherheitsrelevante Entscheidungen oder Prozessaufrufe nutzt, kann daraus Codeausführung entstehen.

Der Angriffsweg in n8n

Bei n8n liegt das Problem konkret in der GSuiteAdmin-Node und der XML-Node. Ein Nutzer mit Berechtigung, Workflows zu erstellen oder zu bearbeiten, kann über einen präparierten Parameter in der Node-Konfiguration Werte auf Object.prototype schreiben. Ein öffentlich dokumentierter Exploit-Weg führt von dort über einen Webhook und die GSuiteAdmin-Node bis zur Manipulation der Umgebungsvariable GIT_SSH_COMMAND: Git respektiert diese Variable und führt sie als Shell-Kommando aus, sobald n8n intern eine SSH-artige Git-URL verarbeitet. Die Kette Webhook → GSuiteAdmin-Node (Pollution) → Git-Aufruf (Codeausführung) zeigt, wie aus einer scheinbar begrenzten Parameter-Manipulation vollständige Remote Code Execution wird.

Wer ist betroffen?

Die Lücke setzt einen bereits authentifizierten Nutzer mit Workflow-Rechten voraus, ist also kein klassischer unauthentifizierter Remote-Angriff. In der Praxis ist das trotzdem relevant, weil n8n-Instanzen in vielen KMU-Setups von mehreren Teammitgliedern mit unterschiedlichem Vertrauensniveau genutzt werden, etwa in Marketing- oder Support-Teams, die eigene Automatisierungen bauen dürfen. Wird ein einzelnes Nutzerkonto kompromittiert (etwa durch Phishing) oder handelt ein interner Nutzer böswillig, lässt sich die Lücke direkt zur vollständigen Serverkompromittierung eskalieren.

Was Admins jetzt tun sollten

1. n8n-Version prüfen: docker exec <container> n8n --version oder im Docker-Compose-File das gepinnte Image-Tag kontrollieren.
2. Auf mindestens Version 2.14.1, 2.13.3 oder 1.123.27 aktualisieren, je nach genutztem Release-Zweig.
3. Bei Docker-Compose-Betrieb: Image-Tag im docker-compose.yml anpassen, dann docker compose pull && docker compose up -d ausführen.
4. Falls ein sofortiges Update nicht möglich ist: Workflow-Erstell- und Bearbeitungsrechte auf vertrauenswürdige Nutzer beschränken.
5. Als kurzfristige Notmaßnahme die XML-Node deaktivieren, indem n8n-nodes-base.xml in der Umgebungsvariable NODES_EXCLUDE eingetragen wird.
6. Diese Workarounds sind laut n8n-Advisory ausdrücklich keine vollständige Absicherung, sondern nur eine Übergangslösung.
7. Nach dem Update prüfen, ob zwischenzeitlich verdächtige Workflow-Änderungen oder unbekannte Git-Aufrufe in den n8n-Logs auftauchen.
8. Backup der n8n-Workflows und Credentials vor jedem Versions-Upgrade nicht vergessen.

Einordnung für KMU

n8n gehört zu den Werkzeugen, die schnell "mal eben" aufgesetzt werden, weil die Docker-Installation simpel ist und der Nutzen für Automatisierung schnell sichtbar wird. Genau das macht Versionspflege oft zum blinden Fleck: Ist der Container einmal läuft, verschwindet er aus dem regulären Patch-Zyklus. CVE-2026-33696 zeigt exemplarisch, warum auch scheinbar interne Tools mit begrenztem Nutzerkreis eine feste Update-Routine brauchen. Ein monatlicher Check der laufenden Container-Images gegen die offiziellen Release-Notes gehört in jede Docker-Betriebsroutine, nicht nur bei klassischen Internet-facing-Diensten.

Passende Anleitungen auf S-EDV

1. n8n mit Docker: KI-Workflows und Automatisierung self-hosted
2. Docker und Docker Compose auf Linux installieren (Ubuntu/Debian): die Self-Hosting-Grundlage

Quellen

1. GitHub Security Advisory: Prototype Pollution in GSuiteAdmin node parameters leads to RCE (GHSA-mxrg-77hm-89hv)
2. The Hacker News: ThreatsDay - Gogs 10.0 RCE, n8n Workflow-to-RCE, $10M Reward, GLM-5.3 AI Exploit, and More
3. Simon Koeck: CVE-2026-33696 - From a Schema Name to RCE in n8n