CrowdSec riconduce il furto di 300 repository GitHub a una dipendenza TanStack malevola

CrowdSec collega il furto di circa 300 repository GitHub a una dipendenza TanStack malevola: esposto codice privato, senza prove di dati clienti.

CrowdSec riconduce il furto di 300 repository GitHub a una dipendenza TanStack malevola
Data Breach

Immagine illustrativa generata con AI

Gli aggressori hanno raggiunto il codice privato tramite una dipendenza software

La società francese di cybersecurity CrowdSec ha confermato che gli aggressori hanno sottratto il codice sorgente di circa 300 repository GitHub, tra cui circa 170 repository privati.

La società ha scoperto la scorsa settimana che il furto era avvenuto nel maggio 2026. La sua indagine ha collegato l'intrusione alla campagna contro la supply chain software di TanStack attribuita a TeamPCP, che ha distribuito 84 artefatti malevoli attraverso 42 pacchetti TanStack.

CrowdSec ritiene che il malware distribuito tramite un pacchetto compromesso abbia ottenuto una API key in grado di leggere il suo codebase privato. A quanto pare, questa credenziale ha consentito agli aggressori di copiare repository sia pubblici sia non pubblici, senza dover ricorrere a una violazione distinta e identificata dell'infrastruttura di produzione principale di CrowdSec.

Il codice privato sottratto riguardava la console SaaS di CrowdSec, alcune routine AWS Cloud, connettori e componenti di automazione. Secondo il resoconto dell'indagine pubblicato da CrowdSec, gli investigatori non hanno trovato prove dell'esposizione di credenziali dei clienti o di altre informazioni a loro relative.

Per il momento, la società valuta l'impatto diretto come interno.

Il probabile percorso dall'installazione del pacchetto all'accesso a GitHub

CrowdSec ha utilizzato un pacchetto TanStack nel maggio 2026, quando gli artefatti malevoli erano attivi. L'ipotesi su cui sta lavorando la società è che il codice eseguito dalla dipendenza compromessa abbia catturato una API key dall'ambiente di sviluppo.

Una API key con autorizzazioni di lettura dei repository può offrire a un aggressore della supply chain un accesso diretto al codice proprietario. Anziché sfruttare separatamente ogni repository, l'aggressore può usare la credenziale considerata affidabile per elencare e scaricare ogni progetto disponibile per quell'identità.

Questo sembra spiegare la portata del furto: sono stati interessati circa 300 repository, più della metà dei quali privati. Le informazioni disponibili non stabiliscono se ogni repository sia stato scaricato integralmente o se gli aggressori abbiano selezionato file specifici da alcuni progetti.

Diversi dettagli tecnici non sono ancora stati resi noti. CrowdSec non ha identificato il pacchetto TanStack esatto, né la versione utilizzata, e non ha pubblicato le autorizzazioni precise della API key, gli eventi rilevanti dell'audit di GitHub o altri indicatori di compromissione. Non sono stati diffusi nomi di file malevoli, hash, domini o indirizzi di rete.

La società ha descritto il probabile periodo di esposizione come una breve finestra nel maggio 2026. Dopo aver identificato il rischio, ha ruotato tutti i token e le credenziali potenzialmente interessati.

Che cosa contenevano i repository sottratti

I repository privati includevano codice a supporto di quattro aree significative delle attività di CrowdSec:

  • La console SaaS di CrowdSec;
  • Alcune routine AWS Cloud;
  • I connettori utilizzati per collegare sistemi o servizi;
  • Funzionalità interne di automazione.

Questo non equivale alla conferma della divulgazione di database dei clienti, password, token di accesso o dati di produzione. CrowdSec ha cercato nei materiali interessati e nel proprio ambiente credenziali, API key, token e altri segreti che avrebbero potuto facilitare il movimento laterale. La società ha dichiarato che, finora, questa attività non ha portato all'identificazione di materiale di questo tipo.

La distinzione è importante, ma l'esposizione del codice sorgente richiede comunque attività di sicurezza. Gli aggressori possono esaminare il codice proprietario alla ricerca di debolezze implementative, interfacce non documentate, ipotesi sull'ambiente cloud, convenzioni interne per la denominazione e logiche che potrebbero agevolare successivi tentativi di intrusione. Anche quando i segreti non sono inseriti deliberatamente, frammenti di configurazione, dati di test, cronologia dei commit e script di automazione possono rivelare dettagli operativi.

CrowdSec sostiene che il codice copiato non possa essere facilmente eseguito al di fuori dell'ambiente originario. La riproduzione dei servizi della società richiederebbe la sua rete, i suoi dati, i suoi strumenti e l'infrastruttura di supporto. Il fornitore ha inoltre dichiarato che il codice SaaS viene sottoposto a audit regolari e che gran parte del materiale sottratto era cambiata in modo sostanziale nei quattro mesi precedenti.

Questi fattori possono ridurre la sfruttabilità immediata. Non rendono però il furto irrilevante.

Non è stata identificata alcuna compromissione dei clienti

CrowdSec non ha trovato prove del furto di credenziali dei clienti o di altre informazioni a loro relative. Non ha inoltre riferito che TeamPCP abbia utilizzato il codice sottratto per accedere a deployment dei clienti, risorse cloud o alla piattaforma SaaS di produzione.

La valutazione attuale è quindi più circoscritta di quanto il numero dei repository potrebbe far pensare a prima vista: la proprietà intellettuale di CrowdSec è stata esposta, ma non è stata accertata una violazione dei dati dei clienti.

Questa conclusione potrebbe cambiare se analisi successive dovessero scoprire credenziali sfuggite alla ricerca iniziale o rilevare attività sospette collegate alle informazioni contenute nel codice. Le indagini sul codice sorgente possono richiedere tempo, perché i segreti potrebbero trovarsi nei commit precedenti, nei branch archiviati, nei file generati o nei log di build, anziché nella versione corrente di un progetto.

CrowdSec ha dichiarato che continuerà a monitorare eventuali comportamenti anomali. La società non ha reso note prove di ulteriori sfruttamenti, estorsioni, pubblicazione dei repository o tentativi di trasformare in armi le vulnerabilità individuate nel codice sottratto.

All'incidente, così come descritto, non si applicano identificativi CVE, punteggi CVSS o valutazioni formali della gravità. Non esiste inoltre alcuna voce associata nel catalogo delle vulnerabilità note sfruttate di CISA. Si tratta di una violazione della supply chain resa possibile da credenziali, non di una vulnerabilità divulgata con una patch del fornitore e una tabella delle versioni interessate.

La risposta si è concentrata sulle credenziali e sul rischio di movimento laterale

La prima misura di contenimento adottata da CrowdSec è stata la rotazione di tutti i token e delle credenziali potenzialmente interessati. L'intervento era necessario perché si sospetta che l'accesso iniziale sia avvenuto tramite una API key, non attraverso una vulnerabilità software risolvibile esclusivamente installando un aggiornamento.

La società ha inoltre cercato materiale sensibile che avrebbe potuto consentire all'aggressore di andare oltre l'accesso ai repository. Gli investigatori hanno esaminato i repository compromessi e analizzato il codice a supporto della console SaaS, delle routine AWS, dei connettori e delle automazioni.

La risposta tuttora in corso comprende:

  1. Il monitoraggio di attività insolite associate alle identità e agli ambienti interessati;
  2. L'analisi dei repository privati alla ricerca di segreti incorporati o presenti nella cronologia;
  3. La valutazione dell'eventuale presenza, nel codice esposto, di percorsi utili verso i sistemi cloud o di produzione;
  4. Il mantenimento degli audit del codice sorgente della piattaforma SaaS;
  5. L'indagine su possibili movimenti laterali a partire dalla credenziale di sviluppo compromessa.

CrowdSec non ha segnalato movimenti laterali. Tuttavia, l'assenza di credenziali rilevate nei file sorgente correnti non esclude di per sé un'esposizione attraverso la cronologia dei repository o sistemi di sviluppo correlati.

Che cosa dovrebbero verificare gli utenti di TanStack e i team di sviluppo

Le organizzazioni che hanno utilizzato pacchetti TanStack durante la finestra di sfruttamento del maggio 2026 dovrebbero verificare la provenienza dei pacchetti e analizzare la cronologia delle dipendenze, dei lockfile, delle build e delle installazioni. Poiché non sono stati divulgati i nomi e le versioni dei pacchetti compromessi rilevanti per CrowdSec, i responsabili della difesa non possono basarsi su un indicatore specifico associato a CrowdSec.

I team dovrebbero individuare le credenziali disponibili agli script di installazione dei pacchetti, ai build runner, alle workstation degli sviluppatori e ai job di continuous integration. Qualsiasi token esposto a questi ambienti dovrebbe essere valutato in base alle autorizzazioni di cui dispone e ruotato nei casi in cui non sia possibile escluderne la compromissione.

Gli amministratori di GitHub dovrebbero verificare l'accesso ai repository alla ricerca di attività insolite di enumerazione, clonazione, download di archivi o utilizzo delle API che coinvolgano identità di sviluppo e automazione. I team cloud dovrebbero inoltre esaminare se il codice dei repository o i sistemi di build contenessero credenziali in grado di raggiungere risorse AWS o altre infrastrutture.

Per le organizzazioni che si integrano con CrowdSec, al momento non ci sono prove del furto di credenziali o informazioni dei clienti del fornitore. I clienti non dovrebbero considerare l'incidente una prova della compromissione dei propri ambienti. Dovrebbero comunque verificare eventuali attività di autenticazione o utilizzo delle API inattese se i loro deployment condividevano credenziali con flussi di lavoro di sviluppo interessati.

L'incidente dimostra la portata di una dipendenza malevola: un singolo pacchetto compromesso può ereditare gli accessi disponibili nell'ambiente che lo esegue. Nel caso di CrowdSec, il risultato sospetto è stato l'accesso a una API key e a centinaia di repository. Resta da capire se il codice sottratto possa aiutare TeamPCP, o un'altra parte che ne entri in possesso, a passare dal furto di proprietà intellettuale a ulteriori attività.

Leggi anche

Fonti

Questo articolo è una rielaborazione originale basata sulle fonti seguenti.

Argomenti correlatiCrowdSecTanStackGitHubsupply chain softwaredipendenza malevolafurto di codiceAPI key
Torna alla home