A marzo 2026 una libreria Python che molti CISO non sapevano di avere in produzione è stata compromessa e ha distribuito malware credential-stealing a migliaia di aziende. La libreria è LiteLLM, un proxy di chiamata ai modelli AI con oltre 95 milioni di download mensili dal repository PyPI. Le versioni infette, 1.82.7 e 1.82.8, sono state caricate il 24 marzo 2026 e contenevano payload progettati per rubare credenziali, muoversi lateralmente in ambienti Kubernetes e installare backdoor persistenti. Tra le vittime documentate c’è Mercor, startup AI valutata 10 miliardi di dollari.
Il gruppo TeamPCP non ha attaccato LiteLLM direttamente. Ha compromesso prima Trivy, uno scanner di vulnerabilità open source che girava nella pipeline CI di LiteLLM senza version pinning, cioè senza un controllo che bloccasse l’aggiornamento automatico a versioni non verificate. Da Trivy l’attaccante è salito a LiteLLM, da LiteLLM è sceso ai clienti finali. È una catena di compromissione di terzo livello che ha richiesto sei settimane di attività preparatoria e ha esposto cinque ecosistemi diversi prima di essere individuata.
CVE-2026-42208: 26 ore tra disclosure e primo exploit
Una vulnerabilità separata da quella della supply chain, identificata come CVE-2026-42208, ha esposto un’iniezione SQL nel proxy LiteLLM con score CVSS 9.3. La patch è uscita il 19 aprile in versione 1.83.7-stable. Il primo tentativo di sfruttamento documentato è stato registrato 26 ore e sette minuti dopo l’indicizzazione dell’advisory nel database GitHub. L’8 maggio CISA ha aggiunto la CVE al proprio Known Exploited Vulnerabilities catalog, dando alle agenzie federali statunitensi tre giorni per patchare.
La finestra di 26 ore tra disclosure e primo exploit attivo è il dato che ridefinisce il timing di risposta accettabile per chi opera AI enterprise. Il rischio è stato classificato anche da CISA nel proprio Known Exploited Vulnerabilities catalog. Le procedure standard di patching, anche nelle aziende con maturità SecOps elevata, ragionano in cicli settimanali. Per le componenti AI critiche, il ciclo settimanale non è più sufficiente: 26 ore è già la finestra in cui un attaccante motivato può completare la prima ondata di compromissioni. Le aziende che non hanno un processo di patching emergenziale dedicato allo stack AI sono già esposte oggi a vulnerabilità che usciranno nei prossimi mesi.
Ventisei ore tra la disclosure e il primo exploit. Il patching settimanale degli stack AI non è più una difesa accettabile.
Cosa nessuno sa contare in azienda
Il problema di fondo che il caso LiteLLM espone è la mancanza di un Software Bill of Materials specifico per lo stack AI in quasi tutte le aziende. Il decennio dei container ha insegnato alle organizzazioni a fare l’inventario delle immagini di base, ma lo stack AI introduce un livello di profondità ulteriore: librerie Python di routing, framework di orchestrazione agenti, librerie di parsing per documenti, connettori MCP, embedding model, vector database. Ogni componente è un possibile vettore, ogni componente arriva con dipendenze a cascata che pochi documentano.
La rilevazione OutSystems di aprile misurava il 94% delle aziende preoccupate per l'”AI sprawl”, cioè per la proliferazione incontrollata di agenti e copiloti negli ambienti enterprise. Il sottoinsieme di quella stessa preoccupazione è il sottobosco di librerie open source che alimentano gli agenti: librerie scelte per velocità di sviluppo, mai sottoposte a review formale, mantenute spesso da uno o due sviluppatori volontari, prive di processi di security audit comparabili a quelli dei prodotti enterprise. LiteLLM ha 95 milioni di download al mese, ma il suo team di mantenitori è una squadra ristretta che fa il proprio lavoro senza la rete di sicurezza che ci si aspetta da componenti critici di stack mission-critical.
Il pattern emerso anche al RSAC 2026 sui framework agentici descrive gli stessi vuoti di sicurezza. La prima componente operativa di risposta è il censimento: scoprire cosa effettivamente gira nelle pipeline AI aziendali, fino al livello delle dipendenze indirette. Strumenti come SBOM specifici (Syft, CycloneDX) integrati nelle CI/CD diventano essenziali. La seconda è il version pinning rigoroso: nessuna libreria critica deve aggiornarsi automaticamente; ogni aggiornamento passa per review umana. La terza è il patching emergenziale: un processo dedicato alle vulnerabilità AI critiche con SLA di 24 ore, non di una settimana.
Le aziende che operano AI in produzione su componenti open source non possono trasferire il rischio a un vendor (perché il vendor non esiste in molti casi) ma possono trasferirlo a un assicuratore. Il mercato cyber insurance sta cominciando a richiedere SBOM per stack AI come condizione per la copertura, e il prezzo del premio comincia a riflettere la maturità della gestione del rischio software. Lo stesso pattern emerso al Kaspersky HORIZONS sulla cyber resilienza enterprise si applica anche qui: la difesa migliore è assumere la compromissione e prepararsi a sopravviverle, non sperare di prevenirla.
La sicurezza dello stack AI non è un problema del modello, è un problema della filiera che lo porta in produzione. LiteLLM è solo il primo episodio noto di una serie di compromissioni che riguarderanno tutto il sottobosco open source dell’AI enterprise nei prossimi mesi. Le aziende che hanno costruito agenti senza censire le dipendenze stanno trasportando un debito di sicurezza che non sanno di avere. Investire oggi in inventario e in processi di patching emergenziale è ordine di magnitudine meno costoso che gestire la prima compromissione, anche solo per la quota di costo reputazionale che resta fuori dall’assicurazione.
#Adessonews seleziona nella rete articoli di particolare interesse.
Se vuoi leggere l’articolo completo clicca sul seguente link
Sara Romano
Source link
