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

Stand: 26. März 2026 – zuletzt aktualisiert

Autor: Mika Schmidt (IT-Security Consultant) – Six Eight Consulting, Fokus: Analyse, IAM, Security Engineering.

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. [Vendor] [Security Advisory] [Security Advisory] [Security Advisory]

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.

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 authentifizierter Angreifer plus Workflow-Bearbeitungsrechten beziehungsweise in der Community Edition aus einem global:member-Konto. [Security Advisory] [Security Advisory] [Security Advisory] [Dokumentation] [Dokumentation]

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. [Vendor]

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. [Security Advisory] [Security Advisory] [Security Advisory]

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 1.123.27, 2.13.3 oder 2.14.1 anheben
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.14.1 -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. [Dokumentation] Die genauen CLI-Befehle für self-hosted n8n sind in der offiziellen Doku dokumentiert. [Dokumentation]

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.

1. Zugriff reduzieren: Nur voll vertrauenswürdige Personen sollten bis zum Patch Workflows erstellen, ändern oder ausführen dürfen.
2. Merge-Node blockieren: Für CVE-2026-33660 nennt n8n als temporären Workaround n8n-nodes-base.merge in NODES_EXCLUDE.
3. XML-Node blockieren: Für CVE-2026-33696 nennt das Advisory n8n-nodes-base.xml in NODES_EXCLUDE.
4. Community Edition prüfen: Generische HTTP-Credentials auditieren und bei Unsicherheit rotieren.
5. Exponierung minimieren: n8n nicht unnötig öffentlich erreichbar lassen und Admin-/Member-Zugänge aufräumen.

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. [Security Advisory] [Security Advisory] [Dokumentation]

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. [Security News]

• 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. [Dokumentation]

FAQ

Reicht es, nur die UI für externe Nutzer zu schließen?

Das reduziert das Risiko, aber es reicht nicht als vollständige Maßnahme. Die Advisories verlangen ein Update; Zugangsbeschränkung ist nur eine temporäre Entschärfung.

Welche Nutzer sind besonders kritisch?

Alle Konten, die Workflows erstellen, ändern oder mit fremden Credentials arbeiten können. In der Community Edition ist für CVE-2026-33663 explizit ein global:member-Konto relevant. [Security Advisory]

Sollte ich nach dem Patch noch Credentials rotieren?

Ja, wenn Sie verdächtige Workflow-Änderungen, unklare Ausführungen oder in der Community Edition unübersichtliche generische HTTP-Credentials feststellen. Das Advisory zu CVE-2026-33663 empfiehlt genau diesen Audit- und Rotationsschritt. [Security Advisory]

Gibt es neben dem Patch noch eine sinnvolle Dauermaßnahme?

Ja: n8n konsequent wie ein Tier-0-System behandeln, Rollen sauber schneiden, öffentliche Exponierung minimieren und Community- oder Spezial-Nodes nur sehr bewusst zulassen. Dafür haben wir bereits eine eigene n8n-Checkliste für sichere Deployments veröffentlicht.