n8n hat am 11. August 2026 den Umfang eines Sicherheitsvorfalls in einer intern genutzten Metabase-Umgebung präzisiert. Ein unautorisierter Dritter hatte Abfragen auf dort verfügbare Daten ausgeführt. Nach der aktualisierten Forensik wurden sieben Datensätze mit Cloud-Benutzernamen und E-Mail-Adressen bestätigt abgerufen. Bei weiteren fünf Datensätzen bestätigte n8n Zugriff auf Namen, Cloud-Benutzernamen, E-Mail-Adressen und bcrypt-gehashte n8n-Cloud-Passwörter. Weitere 62 Datensätze mit Namen und E-Mail-Adressen könnten betroffen sein; n8n konnte den tatsächlichen Abruf einzelner Datensätze nicht bestätigen. Betroffene Personen wurden direkt informiert.
Was direkt informierte n8n-Nutzer priorisieren sollten
n8n empfiehlt direkt kontaktierten Personen, die Anweisungen in der E-Mail zu befolgen und das Passwort schnell zu ändern. Für Unternehmen reicht die Änderung im betroffenen Konto allein möglicherweise nicht, wenn dasselbe oder ein ähnliches Passwort an anderer Stelle verwendet wurde. Dann müssen auch diese Konten einbezogen werden. Ein Passwortmanager und einzigartige Passwörter begrenzen die Folgewirkung. Wo verfügbar, sollte starke Mehrfaktor-Authentifizierung aktiviert und die Kontohistorie auf unbekannte Sitzungen oder Änderungen geprüft werden.
- Direkte Mitteilung von n8n über einen bekannten, selbst aufgerufenen Kanal verifizieren und die dortigen Anweisungen befolgen.
- n8n-Cloud-Passwort ändern und Wiederverwendung oder sehr ähnliche Varianten in anderen Diensten beseitigen.
- Aktive Sitzungen, Kontoeinstellungen, Integrationen und auffällige Anmeldeereignisse prüfen.
- API-Schlüssel und angebundene Credentials nach tatsächlicher Exposition bewerten und bei begründetem Risiko kontrolliert rotieren.
- Interne Security- und Datenschutzverantwortliche informieren, wenn ein Geschäftskonto oder personenbezogene Daten betroffen sind.
Ein bcrypt-Hash ist nicht dasselbe wie ein Klartextpasswort. Er erschwert das direkte Auslesen, entfernt aber das Risiko schwacher oder wiederverwendeter Passwörter nicht vollständig. Wie hoch das konkrete Risiko ist, hängt unter anderem von Passwortstärke und technischer Ausgestaltung ab. Unternehmen sollten deshalb weder behaupten, die Passwörter seien im Klartext offengelegt worden, noch die bestätigte Exposition gehashter Werte verharmlosen.
Welche Maßnahmen n8n und Metabase meldeten
Nach Angaben von n8n schloss Metabase die Schwachstelle, beendete relevante Sitzungen und widerrief die beim Vorfall verwendeten Zugangsdaten. n8n prüfte eigene Auditlogs, rotierte potenziell betroffene Credentials, behandelte Nutzer eines historischen Speicherfehlers und informierte den Datenschutzbeauftragten sowie die Berliner Datenschutzaufsicht. Diese Schritte zeigen wichtige Kategorien einer Incident Response: technische Behebung, Sitzungsentzug, Credential-Behandlung, forensische Eingrenzung, Betroffeneninformation und regulatorische Kommunikation.
Für andere Unternehmen sind diese Kategorien übertragbar, nicht aber n8ns konkretes Ergebnis. Jede Organisation muss eigene Daten, Logs, Verträge und Meldepflichten prüfen. Besonders relevant ist die präzisierte Kommunikation: n8n trennt bestätigten Zugriff, mögliche Betroffenheit und Datensätze ohne sensibles Risiko. Diese sprachliche Trennung verhindert, dass Unsicherheit als Gewissheit ausgegeben wird, und ermöglicht zielgerichtete Maßnahmen für unterschiedliche Gruppen.
Warum interne Analytics-Systeme besonders geprüft werden müssen
Analyseplattformen werden oft als lesende Nebenanwendung behandelt, bündeln aber Daten aus mehreren Systemen. Abfragen, Caches, Exporte und historische Tabellen können Informationen enthalten, die in der produktiven Quelle längst anders geschützt oder gelöscht sind. Der n8n-Fall zeigt aus GNS-Sicht, dass interne Analytik ein eigenes Dateninventar, minimale Zugriffe, kurze Aufbewahrung und technische Owner benötigt. „Intern“ ist keine Sicherheitskontrolle, wenn Sitzungen, Credentials oder Netzwerkpfade zu weit reichen.
- Nur Datenfelder in die Analyseumgebung übernehmen, die für einen dokumentierten Zweck benötigt werden.
- Authentifizierungsdaten und Passwortwerte grundsätzlich aus analytischen Datensätzen ausschließen, sofern kein zwingender und freigegebener Zweck besteht.
- Rollen, Datenquellen, Exporte und Abfrageberechtigungen regelmäßig überprüfen.
- Sitzungen kurz halten, starke Identität verlangen und Dienstzugänge rotierbar gestalten.
- Auditlogs so aufbewahren, dass konkrete Abfragen, Tabellen und Zeiträume später eingegrenzt werden können.
Ein 14-Tage-Review für eigene Analyseplattformen
In den ersten drei Tagen inventarisieren Daten-, Security- und Fachteam angebundene Quellen, sensible Felder und privilegierte Zugänge. Bis Tag sieben werden unnötige Daten entfernt, Rollen begrenzt und Sitzungs- sowie Credential-Regeln geprüft. In der zweiten Woche testet das Team, ob ein Vorfall tatsächlich beantwortet werden könnte: Welche Abfragen liefen, welche Zeilen waren erreichbar, wer nutzte welche Sitzung und welche Exporte entstanden? Fehlende Antworten werden als konkrete Kontrolllücken priorisiert.
Messbar sind Anteil klassifizierter Tabellen, Zahl unnötiger sensibler Felder, privilegierte Nutzer, Dauer bis zum Sitzungsentzug, Rotierbarkeit von Service-Credentials und forensische Abdeckung der Abfragen. Zusätzlich braucht die Kommunikation vorformulierte Kategorien für bestätigt, möglicherweise betroffen und nicht betroffen. So kann ein Unternehmen bei einem Vorfall schnell informieren, ohne zu spekulieren oder wichtige Unsicherheit zu verschleiern.
Die richtige Schlussfolgerung für n8n-Kunden
Der Vorfall ist kein Beleg dafür, dass jede n8n-Instanz oder jeder selbst gehostete Nutzer kompromittiert wurde. n8n erklärt ausdrücklich, dass selbst gehostete Passwörter nicht mit n8n geteilt werden. Direkt informierte Personen sollten handeln; andere können einen Passwortwechsel als zusätzliche Vorsicht erwägen und die eigene Kontosicherheit prüfen. Für Unternehmen liegt der größere Lernwert in der Lieferkette interner Daten: Auch ein Analysewerkzeug braucht dieselbe Sorgfalt bei Datenminimierung, Zugriff, Logs und Incident Response wie produktive Kernsysteme.