CrowdSec: furto sorgenti da 170 repo private, l'offboarding non bastava

Il 16 settembre 2026 il codice sorgente di circa 170 repository privati di CrowdSec è apparso su un forum criminale. L'esfiltrazione era avvenuta il 22 maggio, quattro mesi prima, attraverso il token OAuth di un ex dipendente il cui laptop era stato compromesso dal malware distribuito via npm nell'attacco alla supply chain TanStack. L'incidente, reso noto da CrowdSec il 17-18 settembre, mette in luce un vuoto operativo: l'accesso GitHub era stato mantenuto attivo oltre l'uscita del collaboratore.

La catena dell'attacco: da npm alle repository private

L'attacco ha origine nel pomeriggio dell'11 maggio 2026, quando sono state pubblicate su npm 84 versioni malevole distribuite su 42 pacchetti del namespace @tanstack, secondo l'advisory di sicurezza GitHub. La compromissione del flusso di pubblicazione è avvenuta sfruttando una configurazione errata del workflow GitHub Actions pull_request_target, con tecniche di cache poisoning ed estrazione del token OIDC in runtime.

Il malware installato nelle versioni contaminate raccoglieva token GitHub, credenziali cloud e chiavi SSH dalle macchine degli sviluppatori. Tra le macchine compromesse c'era il laptop di un ex dipendente CrowdSec che aveva ancora accesso all'organizzazione GitHub aziendale. L'OAuth token presente sul dispositivo è stato usato per copiare circa 170 repository privati in un'operazione durata meno di dieci minuti, dalle 05:52:29 alle 06:01:33 UTC del 22 maggio, da un indirizzo IP situato a Toronto, Canada, secondo i log ricostruiti da CrowdSec con il supporto di GitHub.

Il token è stato revocato tre giorni dopo, il 25 maggio, ma l'azienda non aveva rilevato l'esfiltrazione. Il supporto di GitHub ha ricostruito il ciclo di vita del token per confermare il collegamento con la compromissione TanStack.

L'accesso residuo: quando l'offboarding lascia la porta aperta

L'elemento determinante dell'incidente è la persistenza dell'identità digitale oltre il termine del rapporto di lavoro. CrowdSec aveva mantenuto attivo l'accesso GitHub dell'ex dipendente. Al momento dell'evento, l'EDR non era ancora stato distribuito; CrowdSec non attribuisce esplicitamente a questa assenza il mancato rilevamento.

La retention dei log di audit enterprise di GitHub è limitata. Il ritardo di quattro mesi ha reso impossibile un'analisi forense in tempo reale sui log aziendali. È stato il supporto di GitHub a ricostruire retrospettivamente il ciclo di vita del token.

"È davvero ingiusto; non potevamo farci molto, e avrà un impatto negativo su di noi" — Philippe Humeau, CEO di CrowdSec, sulla situazione di CrowdSec come vittima di supply chain

Cosa è stato esposto e cosa no

I repository privati clonati contenevano il codice sorgente della console SaaS, routine AWS Cloud, connettori e automazioni, come ha dichiarato CrowdSec nella sua comunicazione iniziale del 17 settembre. Tra i materiali esfiltrati figurano anche algoritmi di consensus della piattaforma intelligence, script e modelli di data science.

L'esposizione degli algoritmi di consensus è particolarmente rilevante: secondo CrowdSec, la fuga "non consente di compromettere l'integrità della blocklist, ma prima del leak l'attaccante non conosceva esattamente quanti segnali fossero necessari; ora le soglie sono note".

A fianco del codice, sono stati esposti 83 indirizzi email di utenti, corrispondenti a meno dello 0,05% della base di circa 150.000 utenti, e 51 contatti di potenziali investitori del 2020 con nomi, email e contesto di investimento. Il CEO Philippe Humeau ha rivolto scuse personali a questi ultimi.

Un token AWS SNS attivo è stato individuato tra i materiali esfiltrati; è stato testato il 17 agosto 2026 da parte ignota, ma secondo CrowdSec non ha ottenuto accesso aggiuntivo ed era limitato a un singolo topic SNS.

CrowdSec ha escluso categoricamente l'accesso a dati client, credenziali utente, infrastruttura produttiva e database, come ribadito sia nella dichiarazione iniziale sia nel report completo del 18 settembre. Nessun codice è stato modificato dagli attaccanti.

La detection gap: quattro mesi di ritardo

Il ritardo tra esfiltrazione e scoperta — circa quattro mesi — è la dimensione più problematica dell'incidente. CrowdSec stessa ha espresso sorpresa per la cronologia: il 16 settembre è stato "un giorno che è successo", per usare le parole del report aziendale.

Il gap riflette la combinazione di due fattori documentati: assenza di EDR al momento dell'evento, e natura silenziosa dell'esfiltrazione tramite token già autorizzato. L'azienda ha precisato di aver effettuato una caccia attiva a token, credenziali e leak sensibili immediatamente dopo la scoperta, senza trovare vettori di movimento laterale.

Cosa cambia

Secondo l'interpretazione di DeafNews, l'incidente CrowdSec offre tre insegnamenti documentati sul campo.

Primo: la revoca dell'accesso al momento dell'offboarding, senza eccezioni per attività residue, riduce la superficie di attacco. Il brief non specifica se CrowdSec abbia modificato questa pratica dopo l'incidente.

Secondo: la detection di esfiltrazioni tramite token autorizzati richiede monitoraggio comportamentale dei log, non solo presenza di EDR. Il brief non dettaglia quali controlli CrowdSec abbia implementato successivamente.

Terzo: la risposta trasparente di CrowdSec — report tecnico dettagliato, comunicazione delle soglie esposte, scuse agli investitori — rappresenta un modello di disclosure che contrasta con la pratica media del settore. La fonte non specifica se questo approccio sia stato valutato come mitigazione del danno reputazionale.

La ricostruzione si basa principalmente sul report CrowdSec e sull'advisory GitHub; le fonti giornalistiche convergono ma non aggiungono elementi primari indipendenti.

Domande frequenti

I clienti CrowdSec sono a rischio? Secondo l'azienda, no: CrowdSec afferma che nessun dato cliente, credenziale o infrastruttura produttiva è stato accesso. Il CEO ha dichiarato che l'impatto principale riguarda la visibilità del codice sorgente.

La blocklist CrowdSec è compromessa? Secondo CrowdSec, la blocklist non può essere compromessa sulla base delle sole soglie esposte; l'azienda afferma che l'attaccante non può alterarne l'integrità con le informazioni ottenute.

Chiusura editoriale

Il caso CrowdSec è raro per la sua trasparenza documentale. L'azienda ha pubblicato timestamp, indirizzi IP, scope del token e impatto specifico, permettendo una verifica esterna dei fatti. Questo livello di disclosure non elimina il danno — il codice sorgente resta esposto — ma fornisce alla comunità un riferimento concreto sui rischi dell'accesso residuo.

Secondo l'interpretazione di DeafNews, la lezione strutturale è chiara: l'offboarding tecnico deve essere immediato e totale, senza eccezioni operative. Il brief non specifica se CrowdSec avesse procedure scritte in tal senso prima del maggio 2026.

Le informazioni sono state verificate sulle fonti citate.

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti

• https://www.crowdsec.net/blog/tanstack-supply-chain-attack-analysis
• https://www.crowdsec.net/blog/crowdsec-statement-source-code-exposure
• https://github.com/TanStack/router/security/advisories/GHSA-g7cv-rxg3-hmpx
• https://thehackernews.com/2026/09/crowdsec-says-tanstack-npm-attack-led.html
• https://www.securityweek.com/crowdsec-confirms-source-code-stolen-in-supply-chain-attack/
• https://cybersecuritynews.com/tanstack-supply-chain-attack/amp/
• https://bellatorcyber.com/blog/crowdsec-source-code-theft-tanstack-supply-chain-attack
• https://cybersecuritynews.com/weekly-cybersecurity-newsletter-sept-21/amp/
• https://thehackernews.com/
• https://thehackernews.com/p/upcoming-hacker-news-webinars.html
• https://thehackernews.com/search/label/Threat%20Intelligence
• https://thehackernews.com/search/label/Vulnerability