n8n CVE-2026-21877: Kritische RCE im Git-Node

Die Macher von n8n haben eine kritische Lücke mit der Höchstwertung CVSS 10.0 offengelegt. Wer seine Workflow-Automation selbst hostet, riskiert ohne Update einen kompletten Server-Übernahme. Die Lücke trägt die ID CVE-2026-21877 und steckt im Git-Node — und das betrifft fast jede produktive n8n-Installation der letzten Monate.

SCHOCK: Pfad-Check fehlte komplett!

Der Bug klingt klein, ist aber brutal: Im Git-Node hat n8n nicht geprüft, ob ein angegebenes Repo-Verzeichnis ins Dateisystem ausbrechen darf. Die Funktion isFilePathBlocked wurde im File-System-Helper schlicht ignoriert. Dadurch konnten authentifizierte User beliebige Dateien schreiben — und mit einem geschickten Workflow auch direkt Code ausführen.

Genau das macht die Schwachstelle so gefährlich: Wer in deinem n8n-Tenant einen Account hat, springt in einer Mini-Sekunde vom Workflow-Editor in den Container und damit in dein Homelab. Auf vielen Installationen läuft n8n mit Zugriff auf Datenbank-Credentials, API-Keys und SSH-Profile. Ein einziger Klau-Workflow reicht.

BETROFFEN: Alle Versionen ab 0.123.0!

Die Liste ist hart: Alle n8n-Versionen von 0.123.0 bis vor 1.121.3 haben das Problem. Das gilt sowohl für deine selbstgehostete Instanz als auch für n8n Cloud. Auf der Cloud-Seite hat das n8n-Team die Lücke laut eigenem Statement bereits geschlossen — als Self-Hoster bist du selbst verantwortlich.

Der CVSS-Wert von 10.0 ist nicht zufällig: Die Forscher rechnen die Lücke wegen der vollen Kompromittierung der Hostmaschine, der einfachen Triggerbarkeit und der Folgewirkung auf Backend-Systeme so hoch.

SO STOPFST DU DIE LÜCKE in 5 MINUTEN!

Der Fix ist ein simpler Image-Bump. Wer Docker Compose nutzt, erledigt das so:

image: docker.n8n.io/n8nio/n8n:1.121.3
# danach
docker compose pull
docker compose up -d

Vorher: Datenbank sichern, Volume sichern, Workflow-Export ziehen. Danach: Logs prüfen, ob alle aktiven Workflows wieder anlaufen.

EXTRA-TIPP: Bis zum Update Git-Node deaktivieren!

Wenn du nicht sofort patchen kannst — etwa weil eine Migration noch ansteht — gibt es einen Notbremse-Workaround: Deaktiviere den Git-Node in deiner Instanz und entziehe untrusted Usern die Rechte, neue Workflows anzulegen. Damit fällt die Hauptangriffsfläche weg. Trotzdem ist das nur eine Brücke zum Update, kein dauerhafter Schutz.

SO PRÜFST DU, OB DU SCHON BETROFFEN BIST!

Schau dir drei Dinge an:

1. Audit-Logs in n8n: Gibt es Workflow-Ausführungen mit Git-Node-Schritten, die du nicht eingerichtet hast? Verdächtig sind auch Workflows ohne klaren Owner.

2. Container-Filesystem: Ein find / -newer /tmp/anchor -type f 2>/dev/null nach einem frisch gesetzten Anchor-File zeigt alle frisch beschriebenen Dateien. Auffällig: neue Skripte in /tmp, /dev/shm oder unter dem n8n-Daten-Verzeichnis.

3. Cron und systemd-Timer: Sind dort Einträge, die du nicht angelegt hast? Klassische Persistenz-Falle.

FAZIT: SOFORT updaten — keine Diskussion!

n8n ist in vielen Homelabs der zentrale Klebstoff zwischen Diensten. Genau deshalb ist diese Lücke so gefährlich: Ein einziger gestolen Login öffnet einen RCE-Tunnel in dein gesamtes Setup. Update ist Pflicht, Workaround ist Pflaster. Und vergiss nach dem Patch nicht, deine n8n-Credentials zu rotieren — falls jemand die Lücke schon ausgenutzt hat, sitzen seine Tokens noch im RAM oder in einem Workflow-Log.

Quellen

Häufige Fragen

Welche n8n-Versionen sind betroffen?

Betroffen sind alle n8n-Releases ab 0.123.0 bis ausschließlich 1.121.3. Sowohl Self-Host-Installationen als auch n8n Cloud sind verwundbar. Den Fix gibt es in 1.121.3 und neuer. Wer noch auf einer 0.x-Version oder einem 1.x-Release vor 1.121.3 läuft, sollte spätestens jetzt zur aktuellen Stable greifen.

Wie merke ich, ob mein Server angegriffen wurde?

Sieh in den n8n-Audit-Logs nach unbekannten Workflow-Ausführungen mit Git-Node-Schritten. Verdächtig sind plötzliche Schreibzugriffe in fremde Dateipfade oder unerwartete Shell-Aufrufe aus dem n8n-Container. Auch ein Blick in die Crontab und in /tmp lohnt sich. Bei Auffälligkeiten Tokens und Credentials in n8n rotieren.

Wie führe ich das Update sicher durch?

Stoppe deinen n8n-Container, sichere die Datenbank (Postgres oder SQLite) und das Daten-Volume. Ziehe dann das Image n8nio/n8n:1.121.3 oder neuer und starte neu. Nach dem Start prüfe Workflows auf grünen Status. Bei Docker Compose reicht ein image:-Bump und docker compose up -d.

Kann ich das Risiko ohne Update reduzieren?

Ja, vorübergehend. Deaktiviere den Git-Node in deiner n8n-Instanz und verbiete neuen Usern den Zugriff. Das schließt die Hauptangriffsfläche, weil die Lücke im Pfad-Handling des Git-Nodes liegt. Trotzdem solltest du zeitnah updaten — der Fix ist vollständig nur in 1.121.3 und höher.

ALARM bei n8n! CVSS 10 reißt deinen Self-Host-Server auf — JETZT auf 1.121.3 updaten!