CrowdSec ha perso 170 repository privati in nove minuti a causa di una lacuna nell'offboarding

Il 22 maggio 2026, tra le 05:52:29 e le 06:01:33 UTC, qualcuno che operava da un indirizzo IP a Toronto, in Canada, ha usato l'account GitHub di uno sviluppatore che aveva appena lasciato CrowdSec per copiare circa 170 repository privati dell'azienda di sicurezza francese. CrowdSec ha pubblicato quella cronologia nel proprio rapporto sull'incidente il 18 settembre 2026 — la data che l'archivio degli incidenti AI assegna a questo record — dopo che un archivio del suo codice sorgente è emerso sul marketplace di cybercrime pwnforum il 16 settembre. L'account funzionava ancora perché l'azienda aveva deliberatamente lasciato aperto l'accesso GitHub dello sviluppatore così che potesse completare alcuni lavori. Il portatile alle spalle era stato infettato undici giorni prima dal worm ruba-credenziali Mini Shai-Hulud che TeamPCP ha diffuso tramite i pacchetti npm di TanStack. Questo resoconto è tratto dal record depositato il 18 settembre 2026, e l'intero insieme documentato degli incidenti — ogni voce con la propria gravità, il proprio grado di confidenza, il proprio flag di contestazione e le proprie fonti — si trova in the Orca AI Incident Archive, dove questo può essere letto accanto agli altri casi di supply chain dello stesso anno.

Il furto non si è limitato al codice. Il rapporto di CrowdSec ha anche reso noti gli indirizzi email di 83 utenti, presi da un elenco interno di monitoraggio del data science e in gran parte account Gmail, oltre a nome e cognome, indirizzi email e contesto di investimento di 51 potenziali investitori del 2020. Rispetto a circa 150.000 utenti, 83 indirizzi sono una piccola frazione; non è zero. L'amministratore delegato Philippe Humeau ha riservato le sue scuse personali agli investitori: "La divulgazione dei vostri nomi e indirizzi email è un problema di cui parleremo direttamente con voi e con le autorità competenti, e per questo mi scuso personalmente."

Quello che nove minuti hanno davvero comportato

I registri Git che GitHub ha restituito a CrowdSec iniziano alle 05:52:32.138 UTC con un fetch su uno dei repository dell'azienda, e l'attività termina alle 06:01:33. La cifra dell'archivio di circa 170 repository privati deriva da quei dati Git. Nel suo scritto, Humeau descrive l'esposizione come «limitata al codice sorgente di CrowdSecurity, inclusi 130+ repository pubblici e molti privati». DevOps.com, nel riportare l'incidente il 24 settembre, ha indicato in circa 300 repository il totale combinato di pubblici e privati — un numero superiore alla cifra dei repository privati fornita da CrowdSec, e che il rapporto dell'azienda non riporta.

Il contenuto era il normale corredo di un'azienda SaaS in rapida evoluzione: il codice sorgente della console web, gli script di deployment e automazione, e gli script e i modelli di data science alla base delle sue analisi. L'elemento più sensibile che CrowdSec nomina è l'"consensus algorithm" che decide quali indirizzi IP finiscono nelle sue blocklist. L'architettura dell'algoritmo era già pubblica, ma la sua diversità e le sue soglie di rilevamento non lo erano, e ora sono note. Humeau sostiene che le soglie sono un bersaglio mobile e che orientare il consenso richiederebbe comunque una flotta di server ampia e costosa; l'azienda afferma di poterle regolare e di monitorare eventuali discrepanze.

Le credenziali sono state la parte che avrebbe potuto andare molto peggio. "Eravamo molto vicini a essere puliti," ha scritto Humeau. L'unico segreto utilizzabile nel dump era un token di AWS Simple Notification Service, limitato alla pubblicazione su un singolo topic. Qualcuno lo ha testato il 17 agosto 2026 dall'IP 23.234.84.102, chiamando GetCallerIdentity e ListTopics su entrambi i topic dev ed env, senza andare oltre. La maggior parte degli altri token e segreti nel codice era stata revocata o ruotata prima della fuga. CrowdSec afferma che non è stato effettuato alcun accesso alla sua infrastruttura e ai suoi database e che nessun codice è stato modificato nel progetto open source, nel suo codice sorgente privato o nelle sue pipeline di build.

Perché l'account funzionava ancora

Il fallimento dell'offboarding è piccolo e specifico. Quando lo sviluppatore se n'è andato, CrowdSec aveva già rimosso i suoi altri accessi; l'account GitHub è stato mantenuto attivo, ha scritto Humeau, perché «ci siamo lasciati in buoni rapporti con il nostro sviluppatore, e voleva finalizzare un po' di lavoro». L'account è stato rimosso dall'organizzazione GitHub il 25 maggio, tre giorni dopo che i repository erano già stati copiati.

CrowdSec non era in grado di vedere il furto in quel momento, e il motivo merita di essere esposto con precisione. Il token OAuth non era presente nel log di audit dell'organizzazione né in quello di alcun membro attuale, e quando qualcuno è andato a cercarlo non esisteva più: era stato creato, utilizzato e scaduto senza lasciare traccia che l'azienda potesse leggere. GitHub conserva l'attività Git solo su una finestra scorrevole di sette giorni per le organizzazioni non dotate di piano enterprise, come osserva la stessa CrowdSec. La svolta è arrivata dal team di supporto di GitHub, che ha ricostruito l'intero ciclo di vita del token e ha fornito l'attività Git relativa alla finestra di due ore attorno alla copia. È così che l'azienda è risalita all'account di un dipendente che se n'era andato. Il collegamento a TanStack è emerso dalla stessa operazione.

L'archivio trapelato conteneva prove di per sé. Il .github/.git/config al suo interno registrava un URL di origine nella forma oauth2:gho_xxxxxxxxx@github.com, identificando la credenziale come token OAuth di GitHub e corrispondendo alla metodologia documentata di TeamPCP. CrowdSec afferma di aver controllato le macchine degli sviluppatori alla ricerca di pacchetti malevoli e di non aver trovato nessuna delle versioni di TanStack con backdoor nei propri repository — un risultato che definisce inconcludente anziché discolpante.

Chi l'ha fatto e quanto è solida l'attribuzione

CrowdSec attribuisce il download a "uno dei fondatori di BreachForum e a un membro, diencracked", con l'indirizzo del membro indicato come diencracked@cock.li, operativo da un IP di Toronto con il fuso orario della macchina impostato su UTC-4. L'azienda aggiunge una propria precisazione cautelativa nella stessa frase: "Almeno questo è quanto mostrano i dati Git." Il rapporto di Dark Reading del 22 settembre riporta la stessa attribuzione al fondatore di BreachForum e all'handle diencracked.

La campagna upstream è documentata meglio rispetto alle identità che vi sono dietro. I pacchetti di TanStack sono stati compromessi con backdoor l'11 maggio 2026, quando sono state pubblicate 84 versioni dannose in 42 pacchetti; The Hacker News registra la compromissione come CVE-2026-45321 e cita l'avviso di TanStack stesso per il payload finalizzato al furto di credenziali. La cronologia di CrowdSec rileva che il 22 maggio, lo stesso giorno della copia del repository, TeamPCP — tracciato da CrowdSec come UNC6780 — ha rivendicato la responsabilità della compromissione di repository appartenenti a Mistral AI.

Che cosa è stabilito e che cosa non lo è

Accertato: una copia di circa 170 repository privati è avvenuta il 22 maggio 2026, in una finestra di nove minuti, utilizzando l'account GitHub ancora valido di uno sviluppatore andato via — una sequenza ricostruita dai registri di attività Git di GitHub stesso, non inferita. Accertato anche secondo la versione della stessa azienda: l'esposizione di 83 indirizzi email di utenti e i dettagli di 51 potenziali investitori, la revoca del 25 maggio, il token SNS sondato, e la constatazione che nessun codice è stato alterato e che non è stata raggiunta alcuna infrastruttura o database.

Non stabilito: quale pacchetto avvelenato abbia raggiunto il portatile, e quando. CrowdSec afferma chiaramente di non aver identificato né l'uno né l'altro. La scansione del repository dell'azienda è stata inconcludente, e le sue macchine degli sviluppatori sono risultate pulite, il che mal si concilia con un portatile che, per ammissione della stessa azienda, era compromesso. La lacuna è riconosciuta anziché colmata.

Non pubblicato: il lato di GitHub dell'indagine. CrowdSec afferma che il team di supporto di GitHub ha confermato l'origine TanStack, ma The Hacker News osserva che il rapporto dell'azienda non contiene riscontri provenienti da GitHub stesso, e GitHub non ha pubblicato un proprio resoconto del ciclo di vita del token.

Corroborazione: Dark Reading, The Hacker News e DevOps.com hanno ciascuno trattato l'incidente entro una settimana, e tutti e tre si basano sul rapporto di CrowdSec e sull'avviso di TanStack anziché su un esame forense indipendente dei sistemi di CrowdSec. Dark Reading aggiunge commenti di professionisti esterni, tra cui Denis Calderone di Suzu Labs, che ha definito la mancata revoca "roba da primo giorno". Una nota di ricerca della Cloud Security Alliance datata 20 settembre ripete la sequenza, ma il documento contiene una propria dichiarazione di esclusione di responsabilità secondo cui è stato generato con l'assistenza dell'AI e non è stato sottoposto a revisione ufficiale della CSA — cosa da sapere prima che venga conteggiato come un secondo riscontro indipendente. L'archivio assegna al record affidabilità A, contestato falso, danno reale vero.

La prima affermazione, e la correzione

La prima dichiarazione pubblica di CrowdSec, il 17 settembre, affermava che «nessun dato dei clienti, login/password, nome, organizzazione o qualsiasi altra cosa è stato divulgato, e CrowdSec non conserva PII né log dei clienti; l'impatto è limitato a CrowdSec». Ha inoltre prospettato un'ipotesi tecnica: che un componente interno fosse stato compromesso tramite backdoor per rubare una chiave API in grado di leggere codice privato.

Il rapporto più completo, un giorno dopo, ha sostituito quell'ipotesi con la versione del dipendente che se n'è andato e ha reso noti gli 83 indirizzi e i 51 investitori. The Hacker News la descrive come una correzione dell'affermazione precedente. La stessa CrowdSec inquadra la questione in modo più ristretto: gli 83 indirizzi provenivano da un elenco di monitoraggio di data science anziché da registrazioni dei clienti, e i dettagli sugli investitori risalivano al 2020. Entrambe le descrizioni possono essere vere contemporaneamente: gli indirizzi non erano account dei clienti, ed erano comunque dati personali in un dump pubblicato su un forum criminale. L'azienda afferma che avviserà gli utenti e gli investitori coinvolti e segnalerà la fuga di dati alle autorità.

Cosa è cambiato in seguito

• Le credenziali e i token trovati nell'archivio sono stati ruotati la notte del 16 settembre e per tutto il 17 settembre, con il completamento della rotazione rimanente la mattina seguente.

• Il rilevamento e la risposta sugli endpoint è ora implementato sulle postazioni di lavoro e sui laptop delle persone che hanno accesso al codice sorgente o all'infrastruttura di CrowdSec; l'azienda indica Aikido Security come prodotto. Humeau ammette che avrebbe dovuto essere già in atto prima e ammette anche che è improbabile che il computer di un ex dipendente lo stesse eseguendo.

• Le soglie dell'algoritmo di consenso esposte nella fuga di notizie vengono adeguate, con un monitoraggio più rigoroso delle deviazioni statistiche in tutta la rete della blocklist.

• L'azienda si è posta l'obiettivo di ridurre la stessa risposta — inventario, rotazione, analisi forense e divulgazione — da 48 ore a meno di 24.

• Gli utenti e gli investitori interessati vengono contattati direttamente, e la fuga di notizie viene segnalata alle autorità, secondo la formulazione dell'azienda.

Perché questo si trova in un archivio di incidenti AI

Il coinvolgimento dell'IA in questo caso è di natura infrastrutturale, e vale la pena essere precisi su cosa significhi. Nulla nel resoconto di CrowdSec descrive un sistema di IA che prende una decisione durante l'intrusione; l'attore era una persona o più persone che utilizzavano un token rubato. Ciò che rende questo caso un incidente del settore IA è il raggio di impatto. Le librerie di TanStack costruiscono le interfacce di gran parte del software moderno, il worm che ha raccolto il token è progettato per impossessarsi in un solo passaggio di credenziali cloud, SSH e dei provider di modelli, e il materiale copiato da CrowdSec includeva script e modelli di data science, non solo codice applicativo.

La stessa campagna ha raggiunto direttamente le aziende AI. La cronologia di CrowdSec registra TeamPCP rivendicare i repository di Mistral AI il 22 maggio, e The Hacker News riporta che due dispositivi di dipendenti OpenAI sono stati colpiti, con accesso non autorizzato a un insieme limitato di repository di codice interno. L'archivio registra il caso CrowdSec come seconda vittima a valle della compromissione di TanStack di maggio, dopo quei dispositivi del personale OpenAI.

La distanza tra la copia e la sua scoperta è la parte che dovrebbe viaggiare. I repository sono stati acquisiti il 22 maggio; CrowdSec ha appreso della fuga di dati il 16 settembre, quando il team di Fuites Info ha contattato l'azienda in merito al post su pwnforum — 117 giorni dopo, e non dal proprio monitoraggio. Il meccanismo che ha reso possibile il ritardo non era esotico: un account rimasto attivo per tre giorni oltre la fine del suo scopo, un token che non ha lasciato traccia nei log che l'azienda era in grado di leggere e laptop degli sviluppatori privi di rilevamento degli endpoint. CrowdSec, un'azienda che vende soluzioni di rilevamento delle minacce, ne aveva tutti e tre.