Un progetto open source compromesso, uno scanner di sicurezza trasformato in arma, quattro terabyte di dati personali — passaporti, video-colloqui, database — finiti nelle mani di un gruppo di estorsione. La storia dell’attacco supply chain a LiteLLM che ha colpito Mercor non è solo una notizia di cybersicurezza. È il ritratto delle fragilità strutturali di un’industria AI che macina miliardi sulle spalle di lavoratori precari e poi non sa nemmeno proteggerne i dati.
L’ultimo fine settimana di marzo 2026 ha regalato al mondo tech uno di quegli incidenti che dovrebbero far fermare tutti a pensare — ma che, come al solito, finiranno metabolizzati nel ciclo infinito delle news. Mercor, startup californiana dell’AI recruiting valutata 10 miliardi di dollari, ha confermato di essere stata colpita da un attacco informatico legato alla compromissione del progetto open source LiteLLM. Il gruppo hacker Lapsus$ rivendica il furto di 4 terabyte di dati, tra cui codice sorgente, database utenti e — il punto che nessuno dovrebbe sottovalutare — video-colloqui e documenti d’identità di migliaia di lavoratori. La portavoce di Mercor, Heidi Hagberg, ha dichiarato a TechCrunch che l’azienda ha agito «prontamente» per contenere l’incidente. Prontamente. Come se la prontezza contasse qualcosa quando i tuoi dati sono già su un forum del dark web.
Ma questa storia non riguarda solo Mercor. Riguarda un intero modello di sviluppo software — e di business — costruito su una catena di fiducia che si è rivelata fragilissima. Marzo 2026 passerà alla storia come il mese in cui cinque attacchi supply chain in dodici giorni hanno messo in crisi l’ecosistema open source globale. E la domanda vera non è tecnica. È politica: chi beneficia di questa fragilità, e chi ne paga le conseguenze?
Da Trivy a LiteLLM, anatomia di un attacco a cascata
Il punto di partenza di questa storia non è Mercor e nemmeno LiteLLM. È Trivy, lo scanner di vulnerabilità open source di Aqua Security usato da migliaia di aziende e pipeline CI/CD in tutto il mondo. Il 19 marzo 2026, un gruppo di attaccanti noto come TeamPCP è riuscito a comprometterlo — non il codice su GitHub, ma il binario distribuito ufficialmente e le GitHub Actions associate. Lo scanner che doveva proteggere il codice è diventato il veicolo dell’infezione. Un’ironia quasi poetica, se non fosse per le conseguenze.
TeamPCP ha sfruttato un accesso residuo da un incidente precedente mai completamente bonificato — dettaglio che la dice lunga sullo stato della sicurezza anche nelle aziende che della sicurezza fanno il proprio mestiere — per iniettare un malware nelle release ufficiali di Trivy. Il payload raccoglieva credenziali, chiavi SSH, token API, configurazioni Kubernetes: tutto ciò che serve per muoversi lateralmente in un’infrastruttura cloud moderna. Microsoft, Wiz e Palo Alto Networks hanno pubblicato analisi dettagliate di quello che Unit42 ha definito un caso di «weaponizzazione dei protettori», strumenti di sicurezza trasformati in vettori d’attacco. La cosa più inquietante è che il meccanismo era elegante nella sua semplicità: infetti lo scanner, e lo scanner infetta tutto ciò che scansiona. Un cavallo di Troia nel senso più classico del termine.
LiteLLM, il popolare proxy open source che semplifica le chiamate API verso diversi modelli linguistici — OpenAI, Anthropic, Cohere e altri — usava Trivy nella propria pipeline CI/CD per la scansione di sicurezza. Senza pinnare la versione: un errore tecnico banale, ma dalle conseguenze catastrofiche. Lo scanner compromesso ha silenziosamente estratto il token PYPI_PUBLISH di LiteLLM, permettendo a TeamPCP di pubblicare due versioni malevole del pacchetto su PyPI, la 1.82.7 e la 1.82.8. Il payload era un file .pth (litellm_init.pth) che si eseguiva automaticamente ad ogni avvio di un processo Python, con tre stadi: raccolta credenziali, movimento laterale in ambienti Kubernetes, backdoor persistente per esecuzione remota di codice. LiteLLM viene scaricato circa 3,4 milioni di volte al giorno. Le versioni compromesse sono rimaste disponibili per circa tre ore prima che PyPI le mettesse in quarantena. In quelle tre ore, oltre 40.000 download — quarantamila pipeline, server e ambienti di sviluppo potenzialmente infettati.
La catena non si è fermata qui. Tra il 19 e il 31 marzo 2026, TeamPCP ha compromesso cinque progetti open source in rapida successione: Trivy, le GitHub Actions di Checkmarx, LiteLLM, l’SDK Python di Telnyx e Axios. Ogni compromissione generava le credenziali per la successiva, in un effetto domino che ha attraversato ecosistemi diversi — npm e PyPI — e tre diversi meccanismi di distribuzione. ReversingLabs ha documentato quello che ha definito un «attacco supply chain a cascata». L’analisi di Snyk ha rivelato un dettaglio particolarmente disturbante: il worm CanisterWorm, documentato anche da Sysdig, ha poi automatizzato la propagazione compromettendo oltre 47 pacchetti npm, trasformando ogni sviluppatore o pipeline che installava un pacchetto infetto in un vettore inconsapevole di ulteriore diffusione. Cinque attacchi in dodici giorni. Group-IB non ha usato mezzi termini: «Non siamo più di fronte a intrusioni isolate, ma a una compromissione sistematica delle catene di approvvigionamento tecnologiche globali».
Dieci miliardi di valutazione, zero protezione per chi lavora
Mercor si definisce una piattaforma che sta «ridefinendo il futuro del lavoro». Fondata nel 2023 da tre ventenni, ha raggiunto una valutazione di 10 miliardi di dollari dopo un round Series C da 350 milioni guidato da Felicis Ventures nell’ottobre 2025 — cinque volte quella di appena otto mesi prima. Il modello è semplice, e brutale nella sua efficienza: reclutare professionisti qualificati — scienziati, medici, avvocati, ingegneri, scrittori — e metterli al lavoro per addestrare i modelli AI di OpenAI, Anthropic e Google DeepMind. Oltre 30.000 contractor, 1,5 milioni di dollari pagati al giorno, un fatturato annualizzato da mezzo miliardo. Un modello che abbiamo già analizzato parlando di come l’intelligenza artificiale stia ridisegnando il mercato del lavoro, e che qui trova la sua manifestazione più estrema.
Ma il problema immediato non è (solo) il modello di business. È che Mercor accumula una quantità mostruosa di dati personali sensibili: video-colloqui, documenti d’identità — passaporti inclusi — e database con informazioni dettagliate sui lavoratori. Quando il castello di carte della sicurezza crolla, sono queste vite a finire sul dark web. Il punto è che non parliamo di dati astratti, di numeri di carta di credito che si possono bloccare con una telefonata. Parliamo di volti, voci, documenti d’identità. Roba che non puoi cambiare.
Lapsus$, il gruppo di estorsione che ha rivendicato l’attacco, dichiara di aver ottenuto accesso completo all’ambiente VPN Tailscale di Mercor, da cui avrebbe esfiltrato 4 terabyte di dati: 939 GB di codice sorgente, un database utenti da 211 GB, e 3 TB di bucket di storage contenenti video-colloqui e documenti di verifica dell’identità. Tre terabyte di volti, voci e passaporti. Lo stesso gruppo che nel 2022 aveva già violato Microsoft, Nvidia, Samsung e Uber sembra essere tornato con tattiche nuove — più silenziose, orientate all’estorsione diretta piuttosto che alla pubblicazione clamorosa dei dati rubati.
Un dettaglio merita attenzione particolare. Secondo diverse fonti, la compromissione iniziale potrebbe essere stata aggravata dal fatto che alcuni sviluppatori di Mercor avrebbero inserito credenziali di produzione in un assistente di codifica AI con permessi di sistema non limitati. In pratica, un chatbot con accesso a tutto. La stessa tecnologia che Mercor vende e promuove sarebbe stata il vettore della propria vulnerabilità — un’ironia talmente densa che ci si potrebbe tagliare il pane.
Mercor ha minimizzato, dichiarando di essere stata «una delle migliaia di aziende» colpite dall’attacco supply chain a LiteLLM. Tecnicamente vero, ma quando sei l’azienda da 10 miliardi che custodisce passaporti e videocolloqui di decine di migliaia di persone, il «siamo tutti nella stessa barca» suona come una scusa, non come una spiegazione. La domanda che nessuno sembra porre: perché un’azienda che gestisce dati così sensibili dipendeva da una libreria open source senza nemmeno verificarne l’integrità delle release? E perché i suoi sviluppatori davano credenziali di produzione a un chatbot?
Facciamo un passo indietro e guardiamo chi paga davvero il prezzo di questa negligenza. Non sono gli investitori di Mercor, e nemmeno i fondatori ventenni che valgono miliardi sulla carta. Sono i 30.000 contractor — molti dei quali in India e nel Sud globale — che hanno consegnato documenti d’identità e video personali pensando di candidarsi per un lavoro. Persone che, secondo diverse inchieste, vengono pagate 16 dollari l’ora per lavori da professionisti qualificati, che possono essere licenziate senza preavviso quando un progetto chiude, e che ora scoprono che i loro passaporti sono in vendita su un forum criminale. Il capitalismo delle piattaforme nella sua forma più limpida: socializzare i rischi, privatizzare i profitti.
Già a fine 2025, diversi contractor avevano denunciato pratiche discutibili: progetti chiusi dall’oggi al domani, paghe ridotte del 24% senza preavviso, e — secondo un post virale su LinkedIn — la raccolta di dati personali tramite finti colloqui di lavoro, senza reale intenzione di assunzione. Una piattaforma accusata di trattare i lavoratori come risorse usa-e-getta ora si trova nella posizione di non aver saputo proteggere nemmeno i dati più intimi che aveva raccolto da quelle stesse persone. Il GDPR europeo, in teoria, offrirebbe una qualche forma di tutela — ma Mercor opera dalla California, e i suoi contractor sono sparsi in decine di paesi. La giurisdizione diventa un labirinto, e nel labirinto chi ci si perde sono sempre i più deboli.
Open source, fiducia e il paradosso della sicurezza globale
Il punto va detto con chiarezza: l’open source non è il problema. È una delle poche forme di produzione tecnologica che sfugge — almeno parzialmente — alla logica del profitto, e rappresenta un’alternativa concreta al dominio delle big tech. Ma quello che marzo 2026 ha reso impossibile da ignorare è che l’ecosistema open source è diventato un’infrastruttura critica globale — e viene trattato come il giardino di casa di qualcuno.
LiteLLM è un progetto usato da migliaia di aziende, scaricato milioni di volte al giorno, integrato in pipeline di produzione che gestiscono dati sensibili. Eppure le sue credenziali PyPI erano protette da uno scanner che a sua volta non era pinnato a una versione specifica. È come mettere la combinazione della cassaforte su un post-it attaccato alla porta — una porta il cui guardiano è stato comprato dal nemico. La catena di fiducia era lunga, fragile, e nessuno l’ha testata fino a quando non si è spezzata.
Il nocciolo della questione è politico, non tecnico: il modello attuale di sicurezza della supply chain software si basa su una fiducia transitiva che non ha basi solide. Ti fidi di LiteLLM, che si fida di Trivy, che si fida della propria pipeline CI/CD, che si fida di GitHub Actions, che si fida… ogni anello aggiunge fragilità. E quando un attaccante sufficientemente motivato colpisce il primo, tutta la catena crolla. Come abbiamo già scritto parlando delle minacce alla cybersicurezza nel 2026, la superficie d’attacco si allarga ogni giorno — e gli strumenti di difesa diventano essi stessi bersagli.
C’è poi la questione degli assistenti di codifica AI — un tema che meriterebbe un articolo a sé. Se le indiscrezioni sono confermate, sviluppatori di Mercor avrebbero condiviso credenziali di produzione con un assistente AI durante normali sessioni di debug. Non per negligenza deliberata, ma perché questi strumenti sono progettati per sembrare estensioni naturali del flusso di lavoro, e i confini tra ciò che è sicuro condividere con un chatbot e ciò che non lo è diventano sfumati quando lo strumento ha accesso diretto al terminale e al filesystem. È il paradosso dell’efficienza: gli stessi strumenti che promettono di rendere gli sviluppatori più produttivi possono diventare vettori di esfiltrazione accidentale. Un rischio che poche aziende stanno prendendo sul serio, perché affrontarlo significherebbe rallentare — e nel mondo delle startup AI, rallentare equivale a morire.
E qui arriviamo al paradosso più amaro. Le aziende come Mercor, OpenAI, Anthropic — le stesse che valgono decine di miliardi — costruiscono i loro prodotti su fondamenta open source mantenute da comunità di sviluppatori spesso sottopagati o non pagati affatto. Estraggono valore, lo privatizzano, lo moltiplicano attraverso venture capital, e poi quando qualcosa va storto alzano le mani: «Siamo una delle migliaia». Il modello estrattivo che queste aziende applicano al lavoro umano — pagare 16 dollari l’ora a un medico indiano per addestrare l’AI che lo renderà obsoleto — è lo stesso che applicano all’open source: prendere tutto, contribuire il meno possibile, e scaricare il rischio sulla comunità. Chi finanzia la sicurezza dell’infrastruttura open source su cui si reggono aziende da miliardi? Nella stragrande maggioranza dei casi, nessuno. O volontari nel tempo libero.
Le alternative esistono e non sono utopiche. La Open Source Security Foundation lavora da anni per migliorare la sicurezza della supply chain software. Il framework SLSA (Supply-chain Levels for Software Artifacts), le build riproducibili, la firma crittografica dei pacchetti, il pinning rigoroso delle dipendenze — sono tutte pratiche concrete che avrebbero potuto prevenire o mitigare l’attacco a cascata di marzo. Ma richiedono investimenti. Richiedono che le aziende che usano l’open source reinvestano nella sua sicurezza invece di trattarlo come un buffet gratuito. E questo, nel capitalismo delle piattaforme, è come chiedere a un vampiro di donare il sangue.
La lezione di marzo 2026 è scomoda ma limpida: non esiste sicurezza individuale in un ecosistema interconnesso. La tua applicazione è sicura quanto il suo anello più debole — e quell’anello potrebbe essere un progetto mantenuto da una persona sola, uno scanner che non viene auditato, un token protetto da una password e non da un hardware key. La soluzione non è abbandonare l’open source, sarebbe il peggiore degli errori. È smettere di trattarlo come una risorsa da sfruttare e iniziare a difenderlo come ciò che è: un bene comune che va protetto dal basso, con strutture di governance comunitarie, non con l’elemosina delle corporation.
Domande frequenti sull’attacco supply chain a LiteLLM e Mercor
Cos’è un attacco supply chain nel software open source?
Un attacco supply chain sfrutta le relazioni di fiducia tra progetti software per compromettere un componente da cui dipendono migliaia di altri progetti. Nel caso di marzo 2026, il gruppo TeamPCP ha compromesso Trivy (uno scanner di sicurezza), il quale ha portato alla compromissione di LiteLLM su PyPI, che a sua volta ha esposto migliaia di aziende tra cui Mercor. La catena di fiducia tra i progetti diventa il vettore dell’attacco, e ogni anello compromesso apre la porta al successivo.
Quali versioni di LiteLLM sono state compromesse e cosa faceva il malware?
Le versioni 1.82.7 e 1.82.8, pubblicate su PyPI il 24 marzo 2026. Il codice malevolo includeva un file .pth che si eseguiva automaticamente ad ogni avvio di un processo Python nell’ambiente infetto. Il payload operava in tre stadi: raccolta di credenziali e chiavi crittografiche, movimento laterale in ambienti Kubernetes, e installazione di una backdoor persistente per esecuzione remota di codice. Le versioni sono rimaste disponibili per circa tre ore, totalizzando oltre 40.000 download prima della quarantena da parte di PyPI.
Quali dati sono stati rubati nell’attacco a Mercor?
Secondo Lapsus$, il gruppo che ha rivendicato l’attacco, sono stati esfiltrati 4 terabyte di dati attraverso una compromissione dell’ambiente VPN Tailscale dell’azienda. Il bottino includerebbe 939 GB di codice sorgente della piattaforma, un database utenti da 211 GB, e circa 3 TB di bucket di storage contenenti video-colloqui e documenti di verifica dell’identità — inclusi passaporti — di migliaia di contractor che lavorano per addestrare modelli AI.
Come ci si protegge dagli attacchi alla supply chain del software?
Le pratiche fondamentali includono il pinning delle dipendenze a versioni specifiche con hash verificati, l’adozione del framework SLSA per la verifica dell’integrità degli artefatti software, l’autenticazione a più fattori con hardware key per gli account di pubblicazione su registri come PyPI e npm, il monitoraggio continuo delle dipendenze con strumenti di Software Composition Analysis, e l’uso di build riproducibili che permettono di verificare che il codice sorgente corrisponda al pacchetto distribuito.
Chi è TeamPCP e qual è il suo legame con Lapsus$?
TeamPCP è il threat actor responsabile della campagna di attacchi supply chain a cascata di marzo 2026, iniziata con la compromissione di Trivy e proseguita con LiteLLM, Checkmarx, Telnyx e Axios — cinque progetti in dodici giorni. Lapsus$ è un gruppo di estorsione separato, già noto per aver violato Microsoft, Nvidia e Samsung nel 2022, che ha sfruttato le credenziali rubate tramite la compromissione di LiteLLM per colpire specificamente Mercor ed esfiltarne i dati in massa.
Quello che è successo a Mercor attraverso l’attacco supply chain a LiteLLM non è un incidente isolato — è un sintomo. Un sintomo di un’industria che costruisce castelli da miliardi su fondamenta che non vuole pagare per mantenere, che accumula dati sensibili di lavoratori precari senza investire nella loro protezione, e che quando le cose vanno male si nasconde dietro un «siamo tutti nella stessa barca».
Trentamila persone hanno consegnato i propri passaporti e i propri volti a un’azienda che non è riuscita a tenerli al sicuro. Lo scanner che doveva proteggere il codice è diventato l’arma dell’attacco. Gli strumenti AI che dovevano aumentare la produttività hanno spalancato le porte ai criminali. Ogni pezzo di questa storia è un promemoria: la tecnologia non è neutra, e le conseguenze della sua fragilità ricadono sempre su chi ha meno potere.
Il punto non è se ci sarà un prossimo attacco supply chain di questa portata. Il punto è quando — e quanti dati di quante persone finiranno sul dark web prima che qualcosa cambi. L’open source resta una delle migliori risposte possibili alla concentrazione del potere tecnologico, ma solo se smettiamo di trattarlo come una risorsa da saccheggiare e iniziamo a difenderlo come il bene comune che è. Dal basso, con strutture di governance comunitarie. Non con l’elemosina delle corporation.