Kurzfassung

SpiderFoot hat eine kritische Schwachstelle in der Darstellung von Korrelationen. Das Werkzeug übernimmt Inhalte aus externen Scan-Quellen, etwa Server-Banner oder Metadaten, und setzt sie offenbar ohne ausreichendes HTML-Escaping in Titel für die Ergebnisansicht um. Wer die Korrelationsansicht öffnet, kann dadurch präpariertes HTML oder Skriptcode im Browser ausführen.

Der praktische Schaden liegt vor allem beim Operator selbst. Im schlimmsten Fall greifen Angreifer API-Schlüssel ab oder führen Aktionen im Kontext des eingeloggten Nutzers aus. Für Teams, die SpiderFoot für OSINT oder interne Vorerkundung einsetzen, ist das kein Randthema.

Was ist passiert?

Die Schwachstelle betrifft die Art, wie SpiderFoot Titel für Korrelationen erzeugt. Diese Titel stammen aus Daten, die von außen in das Tool laufen. Wenn ein Angreifer solche Quellen manipuliert oder kontrolliert, kann er schädliche HTML-Elemente einschleusen. Beim Laden der Ansicht interpretiert der Browser diese Inhalte dann als aktiven Code.

Das ist klassisches Cross-Site-Scripting im Analyse-Tool. Es braucht dafür keinen Zugriff auf den Server selbst. Es reicht, dass SpiderFoot bösartige Daten aus einer externen Quelle verarbeitet und in der Oberfläche ausspielt.

Technische Details

Laut NVD führt SpiderFoot die HTML-Ausgabe für Korrelations-Titel nicht sauber aus. Betroffen sind Datenquellen wie Server-Banner und Metadaten, also genau die Informationen, die in der Praxis oft aus offenen Diensten, Scans oder Enrichment-Feeds kommen. Ein Angreifer kann dort Elemente mit Event-Handlern platzieren, etwa in einem Titel oder in verwandten Feldern, die später in der UI landen.

Der kritische Moment ist das Öffnen der Korrelationsansicht im Browser. Dann läuft der eingeschleuste Code im Kontext der Weboberfläche. Falls dort API-Schlüssel, Sitzungstoken oder andere sensible Daten verfügbar sind, kann ein Angreifer sie auslesen oder Handlungen anstoßen, die eigentlich dem berechtigten Nutzer vorbehalten sind. Ob zusätzliche Schutzmechanismen im konkreten Deployment greifen, nennt die Quelle nicht.

Wer ist betroffen?

Betroffen sind Instanzen von SpiderFoot, die externe Scan-Daten verarbeiten und die Korrelationsansicht nutzen. Das betrifft vor allem SOCs, Pentester, Threat-Intel-Teams und interne Security-Abteilungen, die das Tool für Reconnaissance oder Auswertung einsetzen. Für Unternehmen im DACH-Raum ist das besonders relevant, wenn SpiderFoot mit API-Zugängen, internen Datenquellen oder sensiblen Enrichment-Diensten verbunden ist.

Privatanwender spielen hier kaum eine Rolle. SpiderFoot ist ein Fachwerkzeug für Security-Teams, kein typisches Consumer-Produkt. Wer es produktiv oder in Laborumgebungen nutzt, sollte die Installation aber ernst nehmen und als potenziell angreifbare Webanwendung behandeln.

Empfohlene Maßnahmen

Wer SpiderFoot einsetzt, sollte die eigene Version sofort gegen einen korrigierten Stand prüfen. Wenn noch kein Patch verfügbar ist oder die Lage unklar bleibt, gehört die Instanz vorübergehend hinter restriktive Zugriffe: nur intern erreichbar, nur für wenige Konten, keine unnötigen API-Keys mit weitreichenden Rechten.

Praktisch heißt das: Korrelationsansicht nicht blind vertrauen, externe Datenquellen prüfen und verdächtige Banner- oder Metadaten-Felder als unsicher behandeln. Admins sollten außerdem Logins, API-Nutzung und Browser-Session-Fehler beobachten. Wenn API-Schlüssel im Spiel sind, gehören sie rotiert, sobald ein möglicher Missbrauch nicht ausgeschlossen werden kann.

Für den Betrieb in Unternehmen gilt außerdem ein einfacher Grundsatz: Security-Tools brauchen dieselbe Härtung wie andere Webanwendungen. Eigene Service-Accounts, minimale Rechte, Zugriffsbeschränkung per Netzsegment und regelmäßige Aktualisierung sind hier Pflicht, nicht Kür.

Einschätzung von CyberSecurity-News.de

Die Schwachstelle ist ernst, weil sie genau dort ansetzt, wo Security-Teams sich meist sicher fühlen: in einem Analysewerkzeug. Das macht den Fehler unangenehm. Ein Angreifer muss kein großes Einfallstor suchen, wenn er nur auf eine Oberfläche zielt, die fremde Daten anzeigt und dabei Browser-Code ausführen lässt.

Die Informationslage ist allerdings dünn. Aus der NVD-Beschreibung geht die Ursache klar hervor, aber Details zu betroffenen Versionen oder zu bereits veröffentlichten Patches nennt die Quelle nicht. Wer SpiderFoot produktiv nutzt, sollte deshalb nicht auf weitere Hinweise warten, sondern die eigene Installation sofort prüfen und absichern. Die Bedrohung ist real, auch wenn für viele Leser kein akuter Massenfall dahintersteht.

Fazit

CVE-2026-75626 ist eine kritische XSS-Schwachstelle in SpiderFoot mit klarem Missbrauchspotenzial. Das Risiko entsteht beim Anzeigen von Korrelationen aus externen Datenquellen. Für Security-Teams kann das den Verlust von API-Schlüsseln oder den Missbrauch der Weboberfläche bedeuten.

Wer SpiderFoot nutzt, sollte die Instanz jetzt prüfen, Zugriffe begrenzen und sensible Zugangsdaten absichern. Gerade bei Tools für OSINT und Reconnaissance lohnt sich sauberes Escaping doppelt.

Quellenangabe

Weiterführende Quelle: NVD: CVE-2026-75626