Drei hoch eingestufte n8n-Secrets-Meldungen im Review
Drei hoch eingestufte n8n-Meldungen zeigen, warum Scan-Revision und Quellkontext vor einer Aussage über offengelegte Zugangsdaten nicht fehlen dürfen.
Mehr als ASPM
Proof-Driven AppSec für Teams, die mit KI entwickeln
Plexicus nutzt AI Swarm Pentest, um autorisierte Anwendungspfade zu erkunden, ausnutzbare Risiken zu validieren und Teams Belege für die Priorisierung der Remediation zu geben.
AI Swarm Pentest ansehenAm 29. Oktober 2026 prüften wir einen repositorybezogenen Plexicus-Ergebnissatz für n8n. Er enthielt 110 Secrets-Meldungen: drei mit hoher und 107 mit mittlerer Einstufung. Diese Zusammenfassung könnte wie ein Nachweis offengelegter Zugangsdaten wirken. Die detaillierten Datensätze belegten das nicht.
Wir untersuchten alle drei hoch eingestuften Datensätze und verglichen ihre Fundstellen mit öffentlichem Quellcode am angeforderten unveränderlichen Snapshot. Zwei Stellen benennen simulierte Konstanten für Zugangsdaten-Namen. Die dritte beginnt eine Zugangsdaten-Typdeklaration. Keine dieser drei Stellen belegt ein nutzbares offengelegtes Geheimnis. Ohne Zuordnung zum tatsächlich gescannten Commit lässt sich zugleich kein endgültiger Fehlalarm des Scanners feststellen.
Was die drei Datensätze belegen
Die Datensätze trugen den Titel „Use of Hard-coded Credentials“. Dateipfad und Zeilennummer waren vorhanden; Quellcode, Scannerbericht und Beschreibung fehlten. Das False-Positive-Flag war falsch. Dieser gespeicherte Bearbeitungszustand ist kein unabhängiger Nachweis für echte Zugangsdaten.
| Gemeldete Stelle | Öffentlicher Code am angeforderten Snapshot | Review-Ergebnis |
|---|---|---|
| CredentialConfig.test.ts, Zeile 1002 | ICredentialType-Deklaration | Metadaten belegen keinen Zugangsdatenwert |
| Confluence-Seitenlöschtest, Zeile 14 | CONFLUENCE_CREDENTIAL_NAME in vi.mock | Ein simulierter Name belegt kein nutzbares Geheimnis |
| Confluence-Anhanglöschtest, Zeile 8 | Gleichartige simulierte Konstante | Der ursprüngliche Scanner-Treffer fehlt |
Der Konfigurationstest, Seitenlöschtest und Anhanglöschtest sind öffentliche, unveränderliche Referenzen. Wir veröffentlichen nur notwendige Bezeichner. Zugangsdatenwerte, private Befundkennungen und vollständige API-Antworten bleiben außerhalb dieses Berichts.
Die fehlende Revision begrenzt das Urteil
Der Eintrag im Open Source Explorer forderte 447fc866bb0a841decfa5e8a29fba06057bfc5bc an. Wir konnten diese Dateien bei upstream unter genau diesem SHA abrufen. Die Datensätze nannten jedoch weder den Scan-Lauf noch dessen tatsächlichen Commit. Repositoryweite Zahlen können Befunde aus anderen Revisionen enthalten.
Wenn sich Zeilen verschieben, beweist eine harmlose Deklaration im angeforderten Snapshot nicht, was der Scanner früher gesehen hat. Eine hohe Einstufung ersetzt fehlende Belege ebenso wenig. Das begrenzte Ergebnis lautet: Die drei verfügbaren Datensätze und ihr Quellkontext belegen keine offengelegten Zugangsdaten. Daraus folgt weder die Sicherheit des gesamten Projekts noch die Fehlerhaftigkeit aller Meldungen.
Eigenes Review-Modell. Die Grafik beschreibt erforderliche Belege und keinen reproduzierten Datenabfluss.
Testcode ist Kontext, keine pauschale Ausnahme
Echte Zugangsdaten können auch in Tests, Fixtures oder Beispielen stehen. Wer alle Testverzeichnisse ausschließt, kann echte Lecks übersehen. Entscheidend ist die Funktion des Werts: Authentifiziert er, benennt er einen Typ, dient er als synthetischer Marker oder verweist er auf ein anderes Objekt?
An den beiden Confluence-Stellen setzt ein simulierter Modulblock eine Namenskonstante und ersetzt die API-Funktion durch ein Test-Double. An der dritten Stelle beginnt ein typisiertes Konfigurationsobjekt. Vor einer Rotationsanforderung oder einem öffentlichen Vorfallbericht braucht der Reviewer daher den ursprünglichen Treffer und die Regelbegründung.
Sollten spätere Belege echte Zugangsdaten nachweisen, müssen der öffentliche Bericht bereinigt und die Widerrufsschritte des Anbieters befolgt werden. Wir haben mit keinem Wert eine Anmeldung versucht und keine Kandidaten an externe Dienste geschickt.
Belege und Entscheidung zusammenhalten
Bewahre Scanner- und Regelversion, gescannten Commit, Quellbereich, bereinigten Treffer, Zugangsdatenkategorie und Begründung auf. Benenne den Verantwortlichen für die Behebung. Eine blockierte Prüfung oder ein fehlender Payload bleibt offen.
Unser Proof-Driven-AppSec-Ablauf verbindet Meldungen mit überprüfbaren Ergebnissen. Das Remediation-Playbook beschreibt den Übergang zu einer geprüften Änderung. Deep Code Analysis behandelt den Quellkontext.
Plexicus liefert die hier verwendeten Metadaten. Die Quellprüfung war eine redaktionelle Untersuchung und kein Nachweis einer automatischen Produktentscheidung. Der Remediation-Ablauf und AI Swarm Pentest beschreiben andere begrenzte Produktabläufe; sie bestätigen diese Meldungen nicht als Lecks.
Nächster Schritt
Fordere Originaltreffer und tatsächliche Scan-Revision an. Gleiche die Zeilen ab, bevor du eine Meldung bestätigst oder verwirfst. Die unveränderlichen Referenzen und das begrenzte Ergebnis helfen dem nächsten Analysten. Dieses Review belegt weder einen n8n-Patch noch einen Widerruf oder eine erfolgreiche Ausnutzung.
Quellen
Scanner-Ausgaben sollen zu einer belastbaren Entscheidung führen? Kontaktiere Plexicus mit Repository-Revision und bereinigten Belegen.
