CrowdSec: Quellcode-Leak über offenes GitHub-Konto

Der französische Sicherheitsanbieter CrowdSec hat am 18.09.2026 einen Bericht zu einem Abfluss seines privaten Quellcodes vorgelegt. Der Weg hinein führte nicht über die Infrastruktur des Unternehmens, sondern über das GitHub-Konto eines Mitarbeiters, der das Unternehmen bereits verlassen hatte, dessen Zugang aber noch offen war, damit er einige Arbeiten abschließen konnte. Für Anwender der CrowdSec Security Engine gibt es nach Herstellerangaben nichts zu tun: Weder der Bericht noch die erste Stellungnahme fordern Nutzer zu Maßnahmen auf. Es gibt keinen Patch und keine Version, die heute eingespielt werden müsste.

Relevant ist der Fall trotzdem, und zwar für zwei Gruppen: für alle, die npm-Pakete auf Entwicklerrechnern installieren, und für alle, die Offboarding-Prozesse verantworten. Denn die eigentliche Lehre steckt nicht in einer Schwachstelle, sondern in der Frage, was in der eigenen Organisation mit Konten, Tokens und OAuth-Verbindungen passiert, wenn jemand geht, und wie lange ein einmal gestohlenes Token danach noch gültig bleibt. Im Fall CrowdSec waren es elf Tage zwischen Diebstahl und Nutzung. S-EDV hat über den zugrunde liegenden TanStack-Angriff bereits aus Sicht von Grafana Labs berichtet, hier kommt ein neuer Angriffsweg hinzu.

Was ist passiert?

Am 11.05.2026 wurden 84 bösartige Versionen von 42 npm-Paketen des TanStack-Projekts veröffentlicht. Der Vorfall wird als CVE-2026-45321 geführt. Wer eine dieser Versionen installierte, führte laut TanStack-Advisory Code aus, der Zugangsdaten vom Rechner abgriff, darunter GitHub-Tokens, SSH-Schlüssel und Cloud-Zugangsdaten. Betroffen war dabei auch der Laptop eines CrowdSec-Mitarbeiters.

Elf Tage später, am 22.05.2026, kopierte ein Angreifer mit einem GitHub-OAuth-Token aus dem Konto dieses ehemaligen Mitarbeiters rund 170 private GitHub-Repositories von CrowdSec. Am 25.05.2026 entfernte CrowdSec das Konto aus seiner GitHub-Organisation, also drei Tage nach dem Kopiervorgang und Monate bevor das Unternehmen überhaupt von einem Leak erfuhr. Die übrigen Zugänge des Mitarbeiters waren bereits entzogen, was laut Unternehmen erklärt, warum in den AWS-Systemen keine verdächtige Aktivität sichtbar war.

Öffentlich wurde der Vorfall erst am 16.09.2026, als der Code in einem Online-Forum auftauchte. Neben dem Quellcode enthielt das Archiv die E-Mail-Adressen von 83 CrowdSec-Nutzern sowie Namen, E-Mail-Adressen und Investitionskontext von 51 potenziellen Investoren aus dem Jahr 2020. Das verwendete Token hinterließ in den von CrowdSec selbst einsehbaren GitHub-Logs keine Spur und existierte zum Zeitpunkt der Entdeckung nicht mehr. Erst der GitHub-Support verfolgte die Historie des Tokens zurück und bestätigte den Verdacht, dass TanStack die Quelle war.

Datum	Ereignis
11.05.2026	84 bösartige Versionen von 42 TanStack-npm-Paketen veröffentlicht (CVE-2026-45321), Laptop eines CrowdSec-Mitarbeiters kompromittiert.
22.05.2026	Angreifer kopiert mit GitHub-OAuth-Token aus dem Konto des ausgeschiedenen Mitarbeiters rund 170 private Repositories.
25.05.2026	CrowdSec entfernt das Konto aus der GitHub-Organisation, drei Tage nach dem Kopiervorgang.
17.08.2026	Versuch, die im Code enthaltene AWS-SNS-Zugangsinformation zu nutzen, laut Unternehmen ohne Erfolg.
16.09.2026	Code taucht in einem Online-Forum auf, Rotation der betroffenen Zugangsdaten am 16. und 17.09.2026.
18.09.2026	CrowdSec veröffentlicht den ausführlichen Bericht, der von der ersten Stellungnahme abweicht.

Was steckt im abgeflossenen Code?

CrowdSec betreibt eine quelloffene Security Engine, die Angriffe auf Servern erkennt. Nutzer, die ihre Erkennungen teilen, erhalten im Gegenzug eine gemeinsame Blocklist bösartiger IP-Adressen. Der abgeflossene Code stammt nicht aus dieser öffentlichen Engine, sondern aus den privaten Repositories. Er umfasst laut Unternehmen die Web-Konsole, Data-Science-Skripte und -Modelle, Automatisierungsskripte sowie den Konsens-Algorithmus, der entscheidet, welche IP-Adressen auf die Blocklists kommen. Der Code sei fast vier Monate alt und habe sich seitdem stark verändert.

Der heikelste Punkt sind die Schwellenwerte des Konsens-Algorithmus, also etwa die Frage, wie viele Erkennungen nötig sind, bevor eine IP-Adresse auf der Blocklist landet. Diese Werte waren vorher nicht bekannt und sind durch den Leak öffentlich. CrowdSec erklärt, nach eigenem Kenntnisstand lasse sich die Blocklist weiterhin nicht vergiften, also nicht dazu bringen, eine harmlose IP zu blockieren. Ein Angreifer bräuchte dafür Dutzende Erkennungen von Dutzenden vertrauenswürdigen Engines aus Dutzenden getrennten Netzen, was sehr teuer wäre. Das Unternehmen weist darauf hin, die Schwellenwerte ändern zu können, was es ohnehin häufig tue.

Zu den Zugangsdaten im Archiv: Die einzige verwendbare Zugangsinformation betraf laut Unternehmen den AWS-Benachrichtigungsdienst SNS und konnte nur Nachrichten an ein einziges Thema veröffentlichen. Am 17.08.2026, einen Monat bevor der Code veröffentlicht wurde, versuchte jemand sie zu nutzen, kam damit aber nicht weiter. Andere Tokens im Code waren bereits rotiert worden oder aus dem Internet nicht nutzbar, soweit das Unternehmen weiß.

Wer ist betroffen?

Direkt betroffen ist zunächst CrowdSec selbst, nach eigenen Angaben ein Anbieter mit rund 150.000 Nutzern. Für Betreiber einer CrowdSec Security Engine ergibt sich aus dem Bericht keine Handlungspflicht: Laut Unternehmen wurde das Konto ausschließlich zum Kopieren von Code verwendet, auf Infrastruktur und Datenbanken wurde nicht zugegriffen und Code wurde nicht verändert.

Nicht betroffen: Betreiber der öffentlichen, quelloffenen CrowdSec Security Engine, deren Code ohnehin einsehbar ist.
Betroffen im engeren Sinn: 83 CrowdSec-Nutzer, deren E-Mail-Adressen im Archiv lagen. Das Data-Science-Team hatte diese Adressen aufbewahrt, um die Produktnutzung zu untersuchen. Das Unternehmen will diese Nutzer kontaktieren.
Ebenfalls im Archiv: 51 potenzielle Investoren aus dem Jahr 2020 mit Namen, E-Mail-Adressen und Investitionskontext. Die Daten stammten aus einem System von 2020, das laut Unternehmen nie öffentlich sein sollte. CrowdSec will den Leak den Investoren und den Behörden melden.
Indirekt relevant: alle Organisationen, die npm-Pakete in Entwicklungsumgebungen installieren, und alle, die Offboarding-Prozesse und Token-Verwaltung verantworten.

Dieselbe TanStack-Kampagne traf weitere Unternehmen. Mistral AI gab an, ein Entwicklergerät sei betroffen gewesen. OpenAI gab an, zwei Mitarbeitergeräte seien betroffen gewesen, mit unautorisiertem Zugriff auf eine begrenzte Menge interner Code-Repositories.

Wie kritisch ist das?

Für Anwender ist die operative Kritikalität gering, es gibt keinen Patch und keine Sofortmaßnahme. Für die Prozessfrage dahinter ist der Fall dagegen aussagekräftig, weil er drei Punkte sehr konkret zeigt.

Erstens überlebt ein gestohlenes OAuth-Token den Diebstahl des Rechners. Hier wirkte es elf Tage nach der Kompromittierung noch, ohne dass ein Passwort oder ein zweiter Faktor im Weg stand.
Zweitens ist ein Zugang, den man beim Offboarding noch kurz offen lässt, ein realer Angriffsweg. Das Konto war genau deshalb noch aktiv, weil der Mitarbeiter einige Arbeiten abschließen sollte.
Drittens hinterlassen solche Tokens in den selbst einsehbaren Logs oft keine Spur. Die Aufklärung hängt dann am Support des Plattformbetreibers, hier an GitHub.

Gesichert ist der zeitliche Ablauf, so wie CrowdSec ihn dokumentiert, und die Bestätigung der Token-Herkunft durch den GitHub-Support. Offen bleibt, ob der Angreifer, der am 22.05.2026 kopierte, identisch ist mit demjenigen, der den Code am 16.09.2026 veröffentlichte. Ebenfalls eine Einschätzung des Unternehmens und keine unabhängig geprüftes Ergebnis ist die Aussage, die Blocklist lasse sich trotz bekannter Schwellenwerte nicht vergiften.

Bericht weicht von der ersten Stellungnahme ab

Der Bericht vom 18.09.2026 unterscheidet sich in mehreren Punkten von der ersten Stellungnahme einen Tag zuvor. Das sollte man kennen, wenn man die erste Meldung gelesen hat und seither von einem anderen Sachstand ausgeht.

Die erste Stellungnahme sagte, es seien keine Kundendaten, Zugangsdaten, Namen, Organisationen oder sonstige Daten abgeflossen und die Auswirkung beschränke sich auf das Unternehmen. Der Bericht listet dagegen die Investorennamen sowie die 83 Nutzer-E-Mail-Adressen auf.
Die erste Stellungnahme nannte den TanStack-Vorfall als sehr wahrscheinliche Quelle und sprach davon, eine intern genutzte Komponente sei offenbar mit einer Hintertür versehen worden, um einen API-Schlüssel zum Lesen des privaten Codes zu stehlen.
Der Bericht sagt dagegen, keine der bösartigen TanStack-Versionen sei im Code von CrowdSec gefunden worden, und verweist stattdessen auf das Konto des ehemaligen Mitarbeiters.

Das ist keine ungewöhnliche Entwicklung: Frühe Stellungnahmen entstehen unter Zeitdruck und mit unvollständiger Forensik. Für Leser heißt es praktisch, dass der Bericht vom 18.09.2026 der aktuellere Stand ist. CEO Philippe Humeau schrieb im Bericht an die Investoren: "for this I personally apologize".

Zur Reaktion des Unternehmens: Die betroffenen Zugangsdaten wurden am 16. und 17.09.2026 rotiert. Zum Zeitpunkt des Vorfalls war auf den Entwicklerrechnern keine Endpoint-Protection-Software vorgeschrieben. Inzwischen läuft solche Software nach Unternehmensangaben auf den Laptops aller Mitarbeiter, die mit Code oder Systemen arbeiten.

Was sollten Admins jetzt tun?

Da kein Produkt gepatcht werden muss, richtet sich die Liste an die eigenen Prozesse. Priorisiert nach Wirkung:

Offboarding-Checkliste prüfen. Werden Zugänge wirklich sofort entzogen? Wenn Ausnahmen nötig sind, damit jemand Arbeiten abschließt, müssen sie dokumentiert, befristet und mit einem Enddatum versehen sein. Genau diese Ausnahme war hier die Lücke.
OAuth-Apps, Personal Access Tokens und Deploy Keys inventarisieren. In GitHub und vergleichbaren Diensten alle bestehenden Autorisierungen auflisten und alles widerrufen, was nicht aktiv gebraucht wird. Besonders alte OAuth-Verbindungen fallen sonst nie auf.
Token-Laufzeiten begrenzen und Rotation erzwingen. Tokens ohne Ablaufdatum sind dauerhafte Zugänge. Ein Token mit kurzer Laufzeit hätte den Zeitraum von elf Tagen zwischen Diebstahl und Nutzung nicht überlebt.
Endpoint-Protection auf Entwicklerrechnern verpflichtend machen. Entwicklergeräte werden oft ausgenommen, weil Werkzeuge stören könnten. Hier war genau das die Ausgangslücke.
npm-Installationen absichern. Lockfiles verwenden, Install-Skripte einschränken und wo möglich einen internen Registry-Spiegel nutzen, damit nicht jede frisch veröffentlichte Version sofort auf Entwicklerrechnern landet.
Audit-Logs der Code-Hosting-Plattform aktivieren und aufbewahren. Ohne gespeicherte Logs fehlt im Ernstfall die Spur, und die Aufklärung hängt komplett am Support des Anbieters.

Einordnung für Unternehmen

Für kleine und mittlere Unternehmen ist der Fall deshalb lehrreich, weil er ohne ausgefeilte Angriffstechnik auskommt. Es gab keine Schwachstelle in einem Produkt von CrowdSec, keine Rechteausweitung und keinen Einbruch in die Infrastruktur. Es gab ein kompromittiertes Notebook, ein gültiges Token und ein Konto, das aus nachvollziehbaren organisatorischen Gründen noch ein paar Tage offen blieb.

Genau diese Konstellation ist in kleineren Organisationen eher häufiger als in großen, weil Übergaben informell laufen und Zugänge oft an einzelnen Personen hängen. Der praktische Test dafür ist einfach: Nehmen Sie den letzten Austritt in Ihrem Unternehmen und prüfen Sie nach, wann welcher Zugang tatsächlich entzogen wurde und ob noch ein Token oder eine OAuth-Verbindung dieser Person existiert. Wenn die Antwort länger als ein paar Minuten Recherche braucht, ist das bereits das Ergebnis.

Zweite Einordnung: Supply-Chain-Vorfälle in npm wirken nicht nur dort, wo das Paket installiert wurde. Der eigentliche Schaden entstand hier erst elf Tage später an einer ganz anderen Stelle, nämlich in der Code-Hosting-Plattform. Wer nach einem npm-Vorfall nur die Pakete zurückrollt, aber keine Zugangsdaten rotiert, behandelt nur die Hälfte des Problems.

Passende Anleitungen auf S-EDV

Grafana Labs und der TanStack-Angriff Hintergrund zum selben npm-Vorfall aus Sicht eines anderen betroffenen Unternehmens.
CrowdSec mit Docker als Intrusion Prevention betreiben erklärt, wie die Security Engine und die gemeinsame Blocklist praktisch funktionieren.
npm und Supply-Chain-Angriffe über Installationsskripte ordnet ein, warum Installationsvorgänge der kritische Moment sind.

Quellen

CrowdSec Blog Übersicht des Herstellerblogs. Der ausführliche Bericht zum Vorfall datiert auf den 18.09.2026, die exakte Einzel-URL des Berichts konnte redaktionell nicht verifiziert werden, daher der Verweis auf die Blog-Übersicht.
The Hacker News, 19.09.2026 Aufbereitung des CrowdSec-Berichts mit Zeitleiste, Angaben zu Mistral AI und OpenAI.
Borns IT- und Windows-Blog, 19.09.2026 deutschsprachige Einordnung des bestätigten Source-Code-Leaks.