CrowdSec verlor 170 private Repositories in neun Minuten durch eine Offboarding-Lücke

Am 22. Mai 2026 nutzte jemand, der von einer IP-Adresse in Toronto, Kanada, aus arbeitete, zwischen 05:52:29 und 06:01:33 UTC das GitHub-Konto eines Entwicklers, der CrowdSec gerade verlassen hatte, um etwa 170 der privaten Repositories des französischen Sicherheitsunternehmens zu kopieren. CrowdSec veröffentlichte diese Chronologie in seinem eigenen Vorfallbericht am 18. September 2026 — dem Datum, das das AI Incident Archive diesem Datensatz zuweist — nachdem am 16. September ein Archiv seines Quellcodes auf dem Cybercrime-Marktplatz pwnforum aufgetaucht war. Das Konto funktionierte noch, weil das Unternehmen den GitHub-Zugang des Entwicklers bewusst offen gelassen hatte, damit er einige Arbeiten abschließen konnte. Der dahinterstehende Laptop war elf Tage zuvor von dem Wurm namens Mini Shai-Hulud infiziert worden, der Anmeldedaten stiehlt und den TeamPCP über die npm-Pakete von TanStack verbreitet hatte. Diese Darstellung stammt aus dem am 18. September 2026 eingereichten Datensatz, und der vollständige dokumentierte Vorfallbestand — jeder Eintrag mit eigenem Schweregrad, eigenem Konfidenzgrad, eigener Disputed-Kennzeichnung und eigenen Quellen — befindet sich in dem Orca AI Incident Archive, wo dieser Eintrag neben den anderen Supply-Chain-Fällen aus demselben Jahr gelesen werden kann.

Der Diebstahl blieb nicht auf Code beschränkt. Der Bericht von CrowdSec legte außerdem die E-Mail-Adressen von 83 Nutzern, die aus einer internen Data-Science-Monitoringliste stammen und überwiegend Gmail-Konten sind, sowie die Vor- und Nachnamen, E-Mail-Adressen und den Investmentkontext von 51 potenziellen Investoren aus dem Jahr 2020. Gemessen an rund 150.000 Nutzern sind 83 Adressen ein kleiner Bruchteil; null sind sie nicht. Seine persönliche Entschuldigung behielt Geschäftsführer Philippe Humeau den Investoren vor: „Dass Ihre Namen und E-Mail-Adressen durchgesickert sind, ist ein Thema, das wir direkt mit Ihnen und den zuständigen Behörden besprechen werden, und dafür entschuldige ich mich persönlich.“

Was neun Minuten tatsächlich erforderten

Die Git-Protokolle, die GitHub an CrowdSec zurückgab, beginnen am 05:52:32.138 UTC mit einem Fetch gegen eines der Repositories des Unternehmens, und die Aktivität endet um 06:01:33. Die im Archiv genannte Zahl von etwa 170 privaten Repositories stammt aus diesen Git-Daten. In seinem Bericht beschreibt Humeau die Offenlegung als „beschränkt auf den Quellcode von CrowdSecurity, darunter 130+ öffentliche Repositories und viele private“. DevOps.com, das am 24. September über den Vorfall berichtete, bezifferte die kombinierte Zahl öffentlicher und privater Repositories auf etwa 300 – eine höhere Zahl als die von CrowdSec selbst genannte Zahl privater Repositories und eine, die der Bericht des Unternehmens nicht nennt.

Der Inhalt bestand aus der üblichen Ausstattung eines schnell wachsenden SaaS-Unternehmens: dem Quellcode der Webkonsole, Deployment- und Automatisierungsskripten sowie den Data-Science-Skripten und -Modellen hinter seiner Analytik. Der sensibelste von CrowdSec genannte Punkt ist der „Konsensalgorithmus“, der entscheidet, welche IP-Adressen auf seine Blocklisten gelangen. Die Architektur des Algorithmus war bereits öffentlich, seine Diversitäts- und Erkennungsschwellen jedoch nicht – und diese sind nun bekannt. Humeau argumentiert, die Schwellen seien ein bewegliches Ziel und eine Steuerung des Konsenses würde weiterhin eine große, teure Serverflotte erfordern; das Unternehmen sagt, es könne sie anpassen und achte auf Abweichungen.

Die Zugangsdaten waren der Teil, der viel schlimmer hätte ausgehen können. „Wir waren sehr nahe daran, sauber zu sein“, schrieb Humeau. Das einzige nutzbare Geheimnis im Dump war ein AWS-Simple-Notification-Service-Token, beschränkt auf das Veröffentlichen in einem einzigen Topic. Jemand testete es am 17. August 2026 von IP 23.234.84.102 aus, rief GetCallerIdentity und ListTopics sowohl für das Dev- als auch für das Env-Topic auf und kam nicht weiter. Die meisten anderen Tokens und Secrets im Code waren vor dem Leak widerrufen oder rotiert worden. CrowdSec gibt an, dass nicht auf seine Infrastruktur und Datenbanken zugegriffen wurde und dass im Open-Source-Projekt, in dessen privatem Quellcode oder in dessen Build-Pipelines kein Code verändert wurde.

Warum das Konto noch funktionierte

Der Offboarding-Fehler ist klein und spezifisch. Als der Entwickler ging, hatte CrowdSec seine übrigen Zugriffsrechte bereits entfernt; das GitHub-Konto blieb laut Humeau aktiv, weil „wir uns im Guten von unserem Entwickler getrennt haben und er einige Arbeit abschließen wollte“. Das Konto wurde aus der GitHub-Organisation am 25. Mai, drei Tage nachdem die Repositories bereits kopiert worden waren, entfernt.

CrowdSec konnte den Diebstahl damals nicht sehen, und der Grund dafür sollte man genau benennen. Das OAuth-Token war weder im Audit-Log der Organisation noch im Audit-Log eines aktuellen Mitglieds vorhanden, und als jemand nachsah, existierte es nicht mehr: Es war erstellt, verwendet und abgelaufen, ohne eine für das Unternehmen lesbare Spur zu hinterlassen. GitHub bewahrt Git-Aktivitäten für Organisationen ohne Enterprise-Plan nur in einem fortlaufenden Sieben-Tage-Fenster auf, wie CrowdSec selbst anmerkt. Der Durchbruch kam vom Support-Team von GitHub, das den vollständigen Lebenszyklus des Tokens nachverfolgte und die Git-Aktivität für das Zwei-Stunden-Fenster rund um das Kopieren lieferte. So gelangte das Unternehmen zum Konto eines ausgeschiedenen Mitarbeiters. Die Verbindung zurück zu TanStack ergab sich aus derselben Untersuchung.

Das durchgesickerte Archiv enthielt seinen eigenen Beweis. Die darin befindliche .github/.git/config zeichnete eine Origin-URL der Form oauth2:gho_xxxxxxxxx@github.com auf, wies die Anmeldedaten als GitHub-OAuth-Token aus und entsprach TeamPCPs dokumentierter Methodik. CrowdSec gibt an, Entwicklerrechner auf schädliche Pakete geprüft und in seinen eigenen Repositories keine der mit Backdoor versehenen TanStack-Versionen gefunden zu haben – ein Ergebnis, das das Unternehmen als nicht aussagekräftig statt als entlastend bezeichnet.

Wer es getan hat und wie sicher die Zuschreibung ist

CrowdSec schreibt den Download „einem der Gründer von BreachForum und einem Mitglied, diencracked“ zu, wobei die Adresse des Mitglieds mit diencracked@cock.li angegeben wird und der Zugriff von einer IP aus Toronto erfolgte, während die Zeitzone der Maschine auf UTC-4 eingestellt war. Das Unternehmen fügt im selben Satz seine eigene Einschränkung hinzu: „Zumindest geht das aus den Git-Daten hervor.“ Der Bericht von Dark Reading vom 22. September enthält dieselbe Zuschreibung an den BreachForum-Gründer und den Handle diencracked.

Die Upstream-Kampagne ist besser dokumentiert als die Identitäten dahinter. Die Pakete von TanStack wurden am 11. Mai 2026 mit Backdoors versehen, als 84 bösartige Versionen in 42 Paketen veröffentlicht wurden; The Hacker News erfasst die Kompromittierung als CVE-2026-45321 und verweist auf TanStacks eigene Sicherheitsmeldung für die Payload zum Diebstahl von Zugangsdaten. CrowSecs Zeitlinie vermerkt, dass am 22. Mai, am selben Tag wie die Kopie des Repositorys, TeamPCP – von CrowdSec als UNC6780 geführt – die Verantwortung für die Kompromittierung von Repositorys übernahm, die Mistral AI gehören.

Was gilt als gesichert und was nicht

Festgestellt:Eine Kopie von etwa 170 privaten Repositories wurde am 22. Mai 2026 in einem neunminütigen Zeitfenster angefertigt, wobei das noch gültige GitHub-Konto eines ausgeschiedenen Entwicklers verwendet wurde – eine Abfolge, die aus GitHubs eigenen Git-Aktivitätsaufzeichnungen rekonstruiert und nicht lediglich abgeleitet wurde. Ebenfalls durch die eigene Darstellung des Unternehmens festgestellt: die Offenlegung von 83 Nutzer-E-Mail-Adressen und der Details von 51 potenziellen Investoren, der Widerruf am 25. Mai, das geprüfte SNS-Token und der Befund, dass kein Code verändert und weder Infrastruktur noch Datenbank erreicht wurde.

Nicht geklärt: welches vergiftete Paket den Laptop erreichte und wann. CrowdSec erklärt unmissverständlich, dass es weder das eine noch das andere identifiziert hat. Der Repository-Scan des Unternehmens blieb ergebnislos, und seine Entwickler-Rechner erwiesen sich als sauber, was in merkwürdigem Widerspruch zu einem Laptop steht, der nach eigener Aussage des Unternehmens kompromittiert war. Die Lücke wird eingeräumt, nicht geschlossen.

Nicht veröffentlicht: GitHubs Seite der Untersuchung. CrowdSec sagt, GitHubs Support-Team habe die TanStack-Herkunft bestätigt, doch The Hacker News merkt an, dass der Bericht des Unternehmens keine Erkenntnisse von GitHub selbst enthält und GitHub keine eigene Darstellung des Lebenszyklus des Tokens veröffentlicht hat.

Bestätigung:Dark Reading, The Hacker News und DevOps.com berichteten jeweils innerhalb einer Woche über den Vorfall, und alle drei bauen auf dem Bericht von CrowdSec und dem Advisory von TanStack auf statt auf einer unabhängigen forensischen Untersuchung der Systeme von CrowdSec. Dark Reading ergänzt Kommentare von externen Praktikern, darunter Denis Calderone von Suzu Labs, der den Revokationsfehler als „Zeug vom ersten Tag“ bezeichnete. Eine Research Note der Cloud Security Alliance vom 20. September wiederholt die Abfolge, doch das Dokument enthält den eigenen Hinweis, dass es mit KI-Unterstützung erstellt wurde und keiner offiziellen CSA-Prüfung unterzogen wurde – wissenswert, bevor es als zweiter unabhängiger Befund gezählt wird. Das Archiv bewertet die Datensatzkonfidenz mit A, „umstritten“ als falsch und „tatsächlicher Schaden“ als wahr.

Die erste Aussage und die Korrektur.

CrowdSecs erste öffentliche Stellungnahme am 17. September besagte, dass „keine Kundendaten, Login/Passwort, Name, Organisation oder sonst etwas geleakt wurde und CrowdSec keine personenbezogenen Daten oder Kundenprotokolle speichert; die Auswirkungen beschränken sich auf CrowdSec“. Sie brachte außerdem eine technische Hypothese ins Spiel: dass eine interne Komponente mit einer Backdoor versehen worden sei, um einen API-Schlüssel zu stehlen, der privaten Code lesen könne.

Der ausführlichere Bericht einen Tag später ersetzte diese Hypothese durch die Darstellung des ausgeschiedenen Mitarbeiters und legte die 83 Adressen und die 51 Investoren offen. Hacker News beschreibt dies als Korrektur der früheren Behauptung. CrowdSecs eigene Darstellung ist enger gefasst: Die 83 Adressen stammten aus einer Monitoring-Liste aus dem Data-Science-Bereich und nicht aus Kundendaten, und die Investorendetails stammten aus dem Jahr 2020. Beide Beschreibungen können gleichzeitig zutreffen – die Adressen waren keine Kundenkonten, und sie waren dennoch personenbezogene Daten in einem Dump, der auf einem Kriminalitätsforum veröffentlicht wurde. Das Unternehmen sagt, es werde die betroffenen Nutzer und Investoren benachrichtigen und den Leak den Behörden melden.

Was hat sich danach geändert?

• Zugangsdaten und Token, die im Archiv gefunden wurden, wurden in der Nacht des 16. September sowie im Verlauf des 17. September rotiert, wobei die verbleibende Rotation am folgenden Morgen abgeschlossen wurde.

• Endpoint Detection and Response ist jetzt auf den Workstations und Laptops der Personen ausgerollt, die an der Codebasis oder Infrastruktur von CrowdSec arbeiten; das Unternehmen gibt {{1}}Aikido Security{{/1}} als Produkt an. Humeau räumt ein, dass es schon früher hätte im Einsatz sein sollen, und räumt außerdem ein, dass es unwahrscheinlich ist, dass es auf dem Rechner eines ehemaligen Mitarbeiters lief.

• Die durch das Leck offengelegten Schwellenwerte des Konsensalgorithmus werden angepasst, begleitet von einer strengeren Überwachung statistischer Abweichungen im gesamten Blocklist-Netzwerk.

• Das Unternehmen hat sich zum Ziel gesetzt, dieselbe Reaktion – Bestandsaufnahme, Rotation, Forensik und Offenlegung – von 48 Stunden auf unter 24 zu verkürzen.

• Betroffene Nutzer und Investoren werden direkt kontaktiert, und das Leck wird nach Angaben des Unternehmens den Behörden gemeldet.

Warum dies in einem KI-Vorfallarchiv liegt

Die Beteiligung von KI ist hier infrastruktureller Natur, und es lohnt sich, genau zu bestimmen, was das bedeutet. In der Darstellung von CrowdSec beschreibt nichts ein KI-System, das während des Eindringens eine Entscheidung trifft; bei dem Akteur handelte es sich um eine Person oder mehrere Personen, die ein gestohlenes Token verwendeten. Was den Fall zu einem Incident der KI-Branche macht, ist der Schadensradius. Die Bibliotheken von TanStack bilden die Schnittstellen eines Großteils moderner Software, der Wurm, der das Token erbeutet hat, ist darauf ausgelegt, Cloud-, SSH- und Modellanbieter-Zugangsdaten in einem Durchgang abzugreifen, und das aus CrowdSec kopierte Material umfasste Data-Science-Skripte und Modelle statt nur Anwendungscode.

Dieselbe Kampagne erreichte KI-Unternehmen direkt. Die Zeitlinie von CrowdSec verzeichnet, dass TeamPCP am 22. Mai Mistral-AI-Repositories beanspruchte, und The Hacker News berichtet, dass zwei Geräte von OpenAI-Mitarbeitenden betroffen waren, wobei unbefugt auf eine begrenzte Anzahl interner Code-Repositories zugegriffen wurde. Das Archiv verzeichnet den CrowdSec-Fall als zweites nachgelagertes Opfer der TanStack-Kompromittierung im Mai, nach diesen Geräten von OpenAI-Mitarbeitenden.

Der Abstand zwischen der Kopie und ihrer Entdeckung ist der Teil, der reisen sollte. Die Repositories wurden am 22. Mai abgegriffen; CrowdSec erfuhr am 16. September von dem Leck, als das Team von Fuites Info das Unternehmen auf den pwnforum-Beitrag ansprach – 117 Tage später und nicht durch seine eigene Überwachung. Der Mechanismus, der die Verzögerung möglich machte, war nicht exotisch: ein Konto, das seinen Zweck um drei Tage überlebte, ein Token, das in den Protokollen, die das Unternehmen lesen konnte, keine Spur hinterließ, und Entwickler-Laptops ohne Endpoint Detection. CrowdSec, ein Unternehmen, das Bedrohungserkennung verkauft, hatte alle drei.