n8n Sicherheitslücken CVE-2026-33696 & CVE-2026-33660: betroffen prüfen, patchen, IOCs

Wer n8n selbst hostet, sollte die neuen Advisories vom 25. März 2026 nicht als reine Routine-Updates behandeln: Zwei Schwachstellen erlauben unter den richtigen Voraussetzungen Remote Code Execution, eine weitere Lücke ermöglicht in der Community Edition den Diebstahl fremder generischer HTTP-Credentials im Klartext.

Dieser Beitrag ist absichtlich operativ geschrieben: zuerst Betroffenheit prüfen, dann fixen, danach IOCs und Hunting. Wenn Sie zusätzlich an der generellen Absicherung Ihrer Instanz arbeiten wollen, ist unser Beitrag zu sicheren n8n-Deployments die passende Ergänzung.

Hinweis zum aktuellen Betrieb: Die folgenden Mindestversionen beziehen sich auf die März-2026-Advisories. Seitdem sind weitere n8n-Advisories vom 22. April und 13. Mai 2026 hinzugekommen, unter anderem zu XML- und HTTP-Request-RCE. Nutzen Sie die untenstehenden Versionsgrenzen deshalb zur historischen Betroffenheitsprüfung, aber aktualisieren Sie produktive Instanzen heute auf den aktuellen Patchstand Ihres Release-Zweigs.

Schnellcheck: Bin ich betroffen?

Wenn mindestens einer der folgenden Punkte auf Ihre Umgebung zutrifft, sollten Sie Ihre Instanz als betroffen oder akut prüfbedürftig behandeln:

Die Versionsgrenzen stammen direkt aus den Advisories. Die Rollen- und Rechtebewertung ergibt sich aus der Kombination aus authentifiziertem Angreifer plus Workflow-Bearbeitungsrechten beziehungsweise in der Community Edition aus einem global:member-Konto.

Was genau wurde gepatcht?

n8n hat am 25. März 2026 insgesamt sechs neue Advisories veröffentlicht. Für die operative Priorisierung sind vor allem diese drei relevant: zwei kritische RCE-Lücken und eine High-Severity-Lücke für Credential-Diebstahl.

Wichtig für die Einordnung: Die beiden kritischen Lücken sind nicht unauthentifiziert, aber in vielen Unternehmen ist genau das dennoch kritisch, weil n8n häufig mehreren internen Personen oder Teams Bearbeitungsrechte gibt. Genau deshalb lohnt sich parallel zum Patch auch ein Blick auf ältere n8n-Themen wie CVE-2026-25049 und die generelle Rollenhärtung.

Fixen: Welche Version brauchen Sie und wie prüfen Sie das?

Laut Advisory sind 1.123.27, 2.13.3 und 2.14.1 die gepatchten Stände. Daraus lässt sich ableiten: Wenn Sie auf einer älteren 1.x-Instanz sitzen, ist 1.123.27 oder höher die Mindestmarke. Wenn Sie bereits auf 2.x sind, sollten Sie auf einen gepatchten unterstützten Branch springen, also mindestens 2.13.3 oder 2.14.1.

Für einen tatsächlichen Rollout im Mai 2026 ist das aber nur die Untergrenze für diese konkrete März-Welle. Die späteren April-/Mai-Advisories verlangen neuere Patchstände; die GitHub Releases nennen am 16. Mai 2026 2.20.9 als aktuellen Stable-Release. Wer jetzt patcht, sollte daher direkt auf den aktuellen stabilen Patchstand des eigenen Release-Zweigs gehen.

Quick Check: Version auslesen und anschließend ein Security-Audit anstoßen.

# Docker / Compose
docker exec -u node -it <n8n-container> n8n --version
docker exec -u node -it <n8n-container> n8n audit

# npm / bare metal
n8n --version
n8n audit

Patch per Docker Compose: Container aktualisieren und Rollout verifizieren.

# Image-Tag in docker-compose.yml auf den aktuellen Patchstand anheben
# Beispiel am 16.05.2026: 2.20.9 statt nur der alten März-Mindestfixstände
docker compose pull
docker compose up -d

# Danach prüfen
docker exec -u node -it <n8n-container> n8n --version
docker exec -u node -it <n8n-container> n8n audit

Patch per Kubernetes: Image austauschen und Rollout abwarten.

kubectl set image deployment/n8n n8n=ghcr.io/n8n-io/n8n:2.20.9 -n <namespace>
kubectl rollout status deployment/n8n -n <namespace>

# Optional: Version im Pod prüfen
kubectl exec -n <namespace> deploy/n8n -- n8n --version

Wenn Sie n8n Cloud nutzen, erfolgt das Update über das Cloud-Dashboard. Dort kann der Instanzinhaber die Zielversion auswählen. Die genauen CLI-Befehle für self-hosted n8n sind in der offiziellen Doku dokumentiert.

Wenn Sie heute noch nicht patchen können: kurzfristige Mitigations

Die Advisories sind hier klar: Workarounds kaufen Zeit, sie beheben die Lücken nicht vollständig.

Beispiel: Beide betroffenen Nodes kurzfristig blockieren.

# Wenn Sie NODES_EXCLUDE noch nicht nutzen:
NODES_EXCLUDE=n8n-nodes-base.merge,n8n-nodes-base.xml

# Danach n8n neu starten

Das Blocking von Nodes ist ein offiziell dokumentierter Mechanismus von n8n und passt zu den beiden Advisory-Workarounds.

IOCs und Hunting-Hinweise

Wichtige Einordnung: In den zum 26. März 2026 verfügbaren Quellen fanden sich noch keine öffentlich bestätigten aktiven Angriffe auf diese drei neuen CVEs. Die folgenden Punkte sind daher abgeleitete Hunting-Indikatoren, keine vendorbestätigten Forensik-Artefakte.

• Unerwartete neue oder geänderte Workflows mit Merge-Node im Modus „Combine by SQL”.
• Ungewöhnliche Workflow-Änderungen durch Member-, Editor- oder Admin-Konten außerhalb normaler Betriebszeiten.
• In der Community Edition unerwartete Nutzung generischer HTTP-Credentials anderer Benutzer oder Projekte.
• Ausgehende HTTP-Verbindungen des n8n-Hosts direkt nach Workflow-Änderungen oder Testausführungen.
• Dateizugriffe des n8n-Prozesses auf lokale Secrets, Konfigurationsdateien oder Systempfade, die im Normalbetrieb nicht benötigt werden.
• Plötzliches Starten von Shell-/Child-Processes durch den n8n-Prozess oder Container.
• Neue Member-Konten oder breiter vergebene Projektrollen ohne fachlichen Anlass.

Praktischer Hunting-Start: Workflows und Credentials exportieren und nach Risikosignalen durchsuchen.

# Exporte erstellen
docker exec -u node -it <n8n-container> n8n export:workflow --all --pretty > workflows.json
docker exec -u node -it <n8n-container> n8n export:credentials --all --pretty > credentials.json

# Nach offensichtlichen Risikosignalen suchen
grep -nE 'Combine by SQL|Merge|XML|GSuite|Google Workspace Admin' workflows.json
grep -nE 'httpBasicAuth|httpHeaderAuth|httpQueryAuth' credentials.json

Wenn Sie in diesem Schritt auffällige Workflows, verdächtige Änderungen oder unklare Credential-Nutzung sehen, behandeln Sie das als potenziellen Incident: Workflows deaktivieren, betroffene Zugangsdaten rotieren, Logs sichern und den Scope sauber eingrenzen. Die CLI-Export-Funktionen und das Audit-Kommando sind offiziell dokumentiert.

FAQ