n8n Supply-Chain-Angriff: Manipulierte Community Nodes stehlen OAuth-Tokens

Nach der kürzlich bekannt gewordenen kritischen n8n-Sicherheitslücke (CVE-2026-21858) rückt die Workflow-Automatisierungsplattform erneut in den Fokus – diesmal durch einen gezielten Supply-Chain-Angriff über manipulierte Community Nodes. [Security News] Dieser Vorfall reiht sich ein in eine Serie von npm-Supply-Chain-Angriffen, wie sie zuletzt mit Shai-Hulud 2.0 für Aufsehen sorgten – ein weiteres klares Signal, dass das npm-Ökosystem gezielt von Angreifern ins Visier genommen wird. (Mehr zu Shai-Hulud 2.0)

Update · 05. Februar 2026

Neue kritische n8n-Schwachstellen: Warum das Supply-Chain-Risiko weiter steigt

Anfang Februar wurden zehn neue n8n-Schwachstellen öffentlich gemacht, darunter sechs kritische (CVSS 9.4). Die Lücken betreffen u. a. Command Injection / Host Command Execution, Sandbox-Escapes, Arbitrary File Write/Read sowie Workflow-Manipulation. [Update / Security News]

Für diesen Artikel ist die Einordnung entscheidend: Ein Supply-Chain-Angriff über Community Nodes ist besonders gefährlich, wenn er auf eine Plattform trifft, die bereits mehrere kritische Primitives (z. B. Breakout/RCE/Write) aufweist. Kurz: Initial Access (Supply Chain) + Exploit-Kette (CVE-Landschaft) ergibt ein Worst-Case-Szenario.

Was Sie jetzt konkret tun sollten

Patch-Stand prüfen & aktualisieren: n8n empfiehlt die Nutzung der aktuellen Stable-Version; aktuell ist 2.6.3 (Beta: 2.7.1). [Vendor]
Legacy-Installationen priorisieren: Mehrere der neuen CVEs betreffen auch ältere 1.x/2.x-Branches – wer „seit längerem läuft“ und selten updated, ist besonders gefährdet. [Update / Security News]
n8n wie Tier-0 behandeln: Netzwerkzugriffe, Credentials, Secrets und ausgehende Verbindungen so absichern/überwachen, als wäre es CI/CD oder Identity.

1. Überblick: Was ist passiert?

Angreifer haben mehrere npm-Pakete veröffentlicht, die sich als legitime n8n-Integrationen ausgaben. Nach der Installation als Community Node forderten sie Nutzer zur OAuth-Authentifizierung externer Dienste auf – etwa Google Ads.

Die eingegebenen Zugangsdaten wurden nicht nur regulär gespeichert, sondern später gezielt entschlüsselt und an externe Server exfiltriert.

2. Einordnung: Warum das perfekt zum ersten n8n-Vorfall passt

Während CVE-2026-21858 eine klassische Server-Side-Schwachstelle darstellt, zeigt dieser Vorfall eine andere, mindestens ebenso gefährliche Perspektive:

Kein Exploit notwendig
Kein ungewöhnliches Verhalten im UI
Reiner Vertrauensmissbrauch über Open-Source-Ökosysteme

Beide Vorfälle haben jedoch eine gemeinsame Eigenschaft: n8n fungiert als hochprivilegierter Kontrollpunkt innerhalb moderner IT-Landschaften.

3. Technische Analyse: Wie der Angriff funktioniert

Community Nodes laufen in n8n ohne Sandbox oder Isolation. Ihr Code wird mit denselben Rechten ausgeführt wie n8n selbst.

Das bedeutet konkret:

Zugriff auf entschlüsselte OAuth-Tokens zur Laufzeit
Zugriff auf Umgebungsvariablen und Dateisystem
Beliebige ausgehende Netzwerkverbindungen

Die bösartigen Nodes nutzen den n8n Master Key, um Tokens aus dem Credential Store zu entschlüsseln und automatisiert zu exfiltrieren. [Research]

4. Warum das ein echtes Supply-Chain-Problem ist

Der Angriff folgt einem klassischen Supply-Chain-Muster:

Veröffentlichung scheinbar legitimer Pakete
Ausnutzung des Vertrauens in bekannte Plattformen
Missbrauch zentraler Automatisierungs-Workflows

Anders als typische npm-Malware zielt diese Kampagne nicht auf Entwickler-Accounts, sondern auf produktive Unternehmens-Credentials.

Parallelen zu Shai-Hulud 2.0: Der n8n-Angriff zeigt erneut, wie verwundbar das npm-Ökosystem für Supply-Chain-Attacken ist. Ähnlich wie bei Shai-Hulud 2.0 nutzen Angreifer hier manipulierte npm-Pakete, um Zugriff auf kritische Unternehmensressourcen zu erlangen. Während Shai-Hulud 2.0 sich selbstreplizierend durch hunderte Pakete ausbreitete und GitHub-Repositories kompromittierte, zielt dieser Angriff gezielt auf n8n-Instanzen ab – beide zeigen jedoch das gleiche Grundmuster: Vertrauen in Open-Source-Pakete wird missbraucht, um produktive Systeme zu infiltrieren.

5. Konkrete Risiken für Unternehmen

Eine kompromittierte n8n-Instanz bedeutet in der Praxis:

Übernahme externer SaaS-Konten (Marketing, Payments, CRM)
Missbrauch von API-Keys mit weitreichenden Rechten
Seitliche Bewegung in Cloud- und DevOps-Umgebungen
Compliance- und Datenschutzverletzungen

In Kombination mit klassischen Schwachstellen wie CVE-2026-21858 entsteht ein hochattraktives Angriffsziel.

6. Konkrete Schutzmaßnahmen

Konsequent patchen (Pflicht):
Aktualisieren Sie auf die aktuelle Stable-Version (derzeit 2.6.3) bzw. eine explizit gepatchte Version Ihres Branches. [Vendor] [Update / Security News]
Community Nodes deaktivieren:
N8N_COMMUNITY_PACKAGES_ENABLED=false [Vendor Warning]
Nur offizielle Integrationen verwenden
Alle Tokens rotieren, falls Community Nodes genutzt wurden
Outbound-Traffic überwachen
n8n als Tier-0-System behandeln

Für eine umfassende, maßgeschneiderte Checkliste für sichere n8n-Deployments (Startups, KMU, Enterprise) empfehlen wir unseren detaillierten Guide: Checkliste: Sichere n8n-Deployments . Dieser behandelt nicht nur Supply-Chain-Risiken, sondern auch Remote Exploits, Credential-Management und weitere kritische Sicherheitsaspekte.

7. Fazit

Der Vorfall zeigt deutlich: Workflow-Automatisierung ist kritische Infrastruktur. n8n vereint Daten, Credentials und Ausführungslogik – und ist damit ein ideales Ziel für moderne Supply-Chain-Angriffe.

Wer n8n produktiv einsetzt, sollte die Plattform mit demselben Sicherheitsanspruch behandeln wie CI/CD-Systeme oder Identity-Provider.

Eine praxisnahe, umfassende Anleitung für sichere n8n-Deployments finden Sie in unserer Checkliste: Sichere n8n-Deployments für Startups, KMU & Enterprise . Diese behandelt systematisch alle relevanten Sicherheitsaspekte – von der Basisabsicherung bis zur Enterprise-Grade-Sicherheit.

Wenn Sie unsicher sind, ob Ihre n8n-Umgebung betroffen ist oder wie Sie diese nachhaltig absichern, empfehlen wir einen IT-Security-Quick-Check .