n8n-Webhooks absichern: was die Phishing-Missbrauchswelle für Ihre eigenen Workflows bedeutet

Sicherheitsforscher von Cisco Talos zählten zwischen Januar 2025 und März 2026 rund 686 Prozent mehr Phishing-E-Mails, die Links über n8n-eigene Webhook-Adressen missbrauchen. Für jedes Unternehmen, das selbst mit n8n arbeitet, heißt das zweierlei: Eine n8n.cloud-Adresse ist kein Vertrauenssiegel – und die eigenen Webhooks sind offener, als der Auslieferungszustand vermuten lässt.

Was Cisco Talos gefunden hat

Talos-Forscher dokumentierten die Kampagne bis mindestens Oktober 2025 zurück und veröffentlichten die Analyse am 15. April 2026. Der E-Mail-Verkehr mit schädlichen n8n-Webhook-Links lag im März 2026 rund 686 Prozent über dem Stand von Januar 2025. Zwei Angriffsmuster dominieren:

• Malware-Auslieferung über einen gefälschten Freigabe-Hinweis. Eine Phishing-Mail gibt sich als geteilter Microsoft-OneDrive-Ordner aus. Der enthaltene Link führt über eine n8n-Webhook-Adresse zu einer Seite mit CAPTCHA-Abfrage; nach deren Bestätigung lädt die Seite eine ausführbare Datei oder ein MSI-Installationspaket herunter, das ein manipuliertes Remote-Management-Tool als Hintertür einrichtet.
• Geräte-Fingerprinting über einen unsichtbaren Tracking-Pixel. Eine zweite Variante bettet ein 1×1-Pixel-Bild in die Mail ein, dessen Adresse ebenfalls auf einen n8n-Webhook zeigt. Öffnet jemand die Mail, löst das Bild eine Anfrage an diese Adresse aus – die Angreifer erfahren so, dass die Mail gelesen wurde, ohne dass ein Klick nötig ist.

Beide Varianten laufen über Webhook-Adressen auf eigenen Subdomains unter app.n8n.cloud – der von n8n Cloud selbst vergebenen Domain.

Warum eine n8n.cloud-Adresse vertrauenswürdig wirkt

Der Grund, warum diese Links funktionieren, ist simpel: Jeder kann sich bei n8n Cloud ein Konto anlegen und bekommt damit eine eigene Subdomain unter app.n8n.cloud für die eigenen Webhook-URLs – dafür reicht bereits ein Konto im 14-tägigen kostenlosen Testzeitraum (laut n8n-Dokumentation mit Pro-Funktionsumfang und einem Limit von 1.000 Ausführungen). Die Cloud Security Alliance beschreibt den Effekt so, dass die Payload-Links dadurch wirken, als kämen sie aus der vertrauenswürdigen n8n-Infrastruktur, statt aus einer unbekannten Angreifer-Domain. Weder E-Mail-Filter noch Mitarbeitende haben einen Grund, eine app.n8n.cloud-Subdomain anders zu behandeln als jede andere Adresse – bis jetzt.

Für den Mittelstand heißt das

Zwei praktische Konsequenzen, unabhängig davon, ob Sie n8n selbst einsetzen oder nicht:

Erstens: Eine E-Mail mit einem n8n.cloud-Link verdient dieselbe Prüfung wie jeder andere unbekannte Link – nicht mehr Vertrauen, nur weil die Domain nach einem bekannten Tool-Anbieter aussieht. Das gehört in die nächste Auffrischung der Phishing-Awareness, nicht nur in die IT-Abteilung.

Zweitens: Nutzen Sie n8n selbst, um Kunden oder Partnern automatisiert Links zuzuschicken – etwa für eine Formularbestätigung oder eine Status-Benachrichtigung –, laufen diese Links über dieselbe Domain, die jetzt in Sicherheitskreisen als Missbrauchsmuster bekannt ist. Es ist nicht ausgeschlossen, dass E-Mail-Sicherheitsfilter auf Empfängerseite diese Linkmuster inzwischen genauer prüfen oder künftig stärker einschränken. Ein Blick in die Zustellstatistik Ihrer eigenen n8n-gestützten Kundenmails ist der einfachste Weg, das für Ihren Fall zu beobachten.

Ihre eigene n8n-Instanz: der Acht-Punkte-Check

Die Talos-Kampagne selbst übernimmt keine fremden Instanzen, sie nutzt eigene. Das eigentliche Risiko für Ihre eigene n8n-Installation liegt an anderer Stelle: n8n sichert einen neu angelegten Webhook laut Dokumentation standardmäßig nicht ab. Ohne gesetzte Authentifizierung und mit leerer IP-Allowlist beantwortet der Node jede Anfrage, die die URL kennt – die Allowlist lässt laut Dokumentation bei leerem Feld ausdrücklich jede Adresse zu. Das ist keine Fehlkonfiguration, sondern der Auslieferungszustand. Acht Punkte, die sich in jeder n8n-Instanz in wenigen Minuten prüfen lassen:

1. Authentifizierung je produktivem Webhook. Prüfen Sie für jeden Webhook-Node, der im Internet erreichbar ist, ob unter „Authentication” etwas anderes als „None” eingestellt ist. n8n bietet laut Dokumentation Basic Auth, Header Auth, JWT Auth oder n8n User Auth (OAuth2) – welche davon passt, richtet sich danach, was die aufrufende Gegenseite unterstützt.
2. IP-Allowlist, wenn der Absender eine feste Adresse hat. Sendet immer derselbe Dienst oder dasselbe System (etwa ein bekanntes CRM oder eine Partner-API mit festen IP-Bereichen), tragen Sie diese im Allowlist-Feld des Webhook-Nodes ein. Das Feld ergänzt die Authentifizierung, ersetzt sie aber nicht.
3. Versionsstand gegen die Ni8mare-Lücke prüfen. Vergleichen Sie Ihre n8n-Version mit der betroffenen Spanne aus dem Abschnitt unten (ab 1.65.0, behoben mit 1.121.0). Jede aktuelle 2.x-Version liegt bereits darüber; betroffen sind ausschließlich ältere, nicht aktualisierte 1.x-Installationen.
4. Editor-Zugang nicht ungeschützt veröffentlichen. Die Webhook-URLs sind nur ein Teil der Angriffsfläche – der Login-Bereich von n8n selbst gehört nicht ohne Zugriffsbeschränkung (eigenes Benutzerkonto reicht dafür allein nicht, ein zusätzlicher Netzwerkschutz wie VPN oder IP-Beschränkung ist der sicherere Weg) ins offene Internet.
5. n8n.cloud-Links in der eigenen Kommunikation kennzeichnen. Verschicken Sie selbst automatisierte Links über n8n, sagen Sie Empfängern im selben Satz, warum die Mail kommt und was der Link tut – das macht es einfacher, Ihre eigenen legitimen Links von einer Phishing-Mail zu unterscheiden, die dasselbe Domain-Muster ausnutzt.
6. Signaturen prüfen, wenn der Absender das anbietet. Schickt ein Dienst signierte Anfragen – etwa GitHub mit dem Header X-Hub-Signature-256 oder Stripe mit Stripe-Signature –, übernimmt n8n diese Prüfung nicht von selbst: Eine native Signaturprüfung im Webhook-Node gibt es laut einem Feature-Vorschlag im offiziellen n8n-Community-Forum bislang nicht, Nutzer behelfen sich mit einem eigenen Code-Node oder einem externen Dienst. Ohne diesen zusätzlichen Schritt verarbeitet der Workflow auch eine Anfrage, die nur so aussieht, als käme sie vom echten Absender.
7. Bei Reverse Proxy: N8N_PROXY_HOPS setzen. Läuft Ihre self-gehostete Instanz hinter einem Reverse Proxy (Nginx, Caddy, Traefik), ist die Umgebungsvariable N8N_PROXY_HOPS laut Dokumentation standardmäßig auf 0 gesetzt und muss auf die Zahl der Proxy-Stufen stehen. Mehrere unabhängige Praxisanleitungen beschreiben denselben Fehlermodus, wenn das unterbleibt: n8n sieht dann nur die interne Adresse des Proxys statt der echten Absender-IP, die IP-Allowlist aus Punkt 2 vergleicht die falsche Adresse und lässt entweder alles oder nichts durch, ohne dass das auffällt – testen Sie deshalb nach der Einrichtung mit einem echten Aufruf, welche Adresse n8n tatsächlich protokolliert.
8. Anfragerate begrenzen und fehlgeschlagene Versuche beobachten. Eine Drosselung eingehender Anfragen bietet n8n für Webhooks nicht: Die eingebaute Ausführungsbegrenzung (N8N_CONCURRENCY_PRODUCTION_LIMIT) ist laut Dokumentation standardmäßig deaktiviert und reiht überzählige Ausführungen nur in eine Warteschlange ein, statt eingehende Anfragen selbst abzulehnen – wer die URL kennt oder systematisch errät, kann sie beliebig oft aufrufen. Begrenzen Sie die Anfragerate deshalb eine Ebene davor, am Reverse Proxy oder einem vorgeschalteten Dienst, und beobachten Sie fehlgeschlagene Authentifizierungsversuche: Ein plötzlicher Anstieg ist ein Hinweis darauf, dass jemand die Adresse systematisch abtastet.

Die Lücke, die zeigt, dass offene Webhooks kein theoretisches Risiko sind

Dass ein offener Webhook mehr ist als ein Randrisiko, zeigt ein konkreter Fall aus der n8n-eigenen Versionsgeschichte: CVE-2026-21858, von Sicherheitsforschern „Ni8mare” genannt, erhielt die höchste CVSS-Einstufung von 10.0. Laut dem GitHub Security Advisory GHSA-v4pr-fm98-w9pg ermöglichte ein Fehler in der Verarbeitung von Webhook- und Formular-Anfragen unauthentifizierten Zugriff auf Dateien des zugrunde liegenden Servers – über bestimmte formularbasierte Workflows, ohne dass sich ein Angreifer vorher anmelden musste. Betroffen waren alle Versionen ab 1.65.0 bis unter 1.121.0; behoben ist die Lücke mit Version 1.121.0. Zum Vergleich: Die aktuelle stabile n8n-Version lag laut den offiziellen GitHub-Releases am 4. November 2026 bei 2.46.6 – wer eine Version aus der betroffenen 1.x-Spanne betreibt, läuft nicht nur einer, sondern vielen seitdem veröffentlichten Versionen hinterher.

Die beiden Themen dieses Beitrags sind technisch getrennt: Die Phishing-Kampagne von Talos missbraucht Webhooks, die Angreifer selbst bei n8n Cloud anlegen; Ni8mare betraf Schwachstellen in älteren, selbst gehosteten Installationen. Beide zeigen aber denselben Punkt: Ein Webhook ist eine offene Tür, die so lange offensteht, bis jemand sie aktiv absichert – ob diese Tür bei n8n selbst liegt oder in Ihrer eigenen Instanz.

Wer die eigene n8n-Instanz ohnehin regelmäßig auf Fehler und Ausfälle prüft, kann den Versions- und Auth-Check in denselben Rhythmus legen wie das Monitoring der eigenen Workflows. Wer n8n selbst hostet, statt die Cloud-Variante zu nutzen, trägt diese Prüfung ohnehin schon als Teil der eigenen Betriebsverantwortung – mehr dazu in unserem Beitrag zu n8n und Self-Hosting.

FAQ

Ist meine eigene n8n-Instanz durch die von Cisco Talos beschriebene Kampagne direkt angegriffen worden?

Nicht automatisch. Die von Talos dokumentierte Kampagne nutzt Webhook-Adressen, die die Angreifer über eigene, bei n8n Cloud registrierte Konten selbst anlegen – sie übernehmen dafür keine fremden Instanzen. Ihre eigene n8n-Installation ist davon nur betroffen, wenn jemand sie direkt angreift, zum Beispiel über eine ungesicherte Webhook-URL oder eine ungepatchte Sicherheitslücke wie die unten beschriebene.

Wie finde ich heraus, ob meine n8n-Version die Ni8mare-Lücke (CVE-2026-21858) noch enthält?

Öffnen Sie in n8n den Menüpunkt mit der Versionsanzeige (je nach Oberfläche unter den Einstellungen oder im Hilfe-Menü sichtbar) und vergleichen Sie die Nummer mit der betroffenen Spanne: Laut GitHub Security Advisory GHSA-v4pr-fm98-w9pg sind alle Versionen ab 1.65.0 bis unter 1.121.0 betroffen, behoben ist die Lücke mit Version 1.121.0. Jede 2.x-Version liegt bereits oberhalb dieser Spanne. Bei Unsicherheit ist ein Update auf die jeweils aktuelle Version der sicherere Weg, unabhängig davon, ob Sie Formular-Workflows aktiv nutzen.

Reicht eine Authentifizierung am Webhook-Node als Schutz?

Sie schließt die Lücke, die laut n8n-Dokumentation sonst besteht: Ohne gesetzte Authentifizierung und ohne gefüllte IP-Allowlist akzeptiert ein Webhook Anfragen von jeder Adresse, die die URL kennt. Header Auth, Basic Auth, JWT Auth oder n8n User Auth schließen diese offene Tür. Zusätzlich lohnt sich die IP-Allowlist, wenn der Absender aus einem bekannten, festen Adressbereich sendet – beide Maßnahmen schließen unterschiedliche Lücken und ergänzen sich.

Muss ich bei E-Mails mit einem n8n.cloud-Link grundsätzlich misstrauisch sein?

Ja, genauso wie bei jedem anderen Link, den Sie nicht selbst erwarten. Die n8n-Domain ist kein Vertrauenssiegel – sie gehört einer Plattform, bei der sich jeder kostenlos ein Konto anlegen kann, auch Angreifer. Prüfen Sie wie bei jeder Phishing-Mail, ob Absender und Anlass zusammenpassen, bevor Sie einem Link folgen, unabhängig davon, welche Domain er trägt.

Wie oft veröffentlicht n8n Sicherheitsupdates, und muss ich jedes Update sofort einspielen?

Laut den offiziellen Release Notes veröffentlicht n8n in den meisten Wochen eine neue Minor-Version – das sind überwiegend Funktionserweiterungen und Fehlerkorrekturen, nicht jede davon betrifft die Sicherheit. Taucht Ihre Version dagegen namentlich in einem Security Advisory wie dem oben genannten auf, sollten Sie zeitnah aktualisieren – wie dringend, richtet sich danach, ob Ihre Instanz öffentlich erreichbar ist und welche Workflows darauf laufen.