Pacchetto AI compromesso porta al furto di un terabyte di credenziali

Un attacco supply chain può trasformare un componente affidabile in un punto di raccolta per credenziali, chiavi API e token di autenticazione.

È il modello emerso dalla campagna attribuita a TeamPCP, che tra marzo e aprile 2026 ha colpito strumenti di sviluppo e sicurezza come Trivy, Checkmarx KICS, LiteLLM e il pacchetto Python di Telnyx.

Il codice malevolo è entrato in workflow GitHub Actions, estensioni e pacchetti PyPI, raggiungendo gli ambienti delle organizzazioni che li utilizzavano. Una ricerca di CloudSEK ha ricostruito oltre 434.000 pipeline CI/CD potenzialmente esposte e più di 2.500 organizzazioni interessate dal caso LiteLLM. Il caso conferma che una dipendenza legittima può diventare un accesso privilegiato alla rete aziendale.

Da Trivy alle infrastrutture AI

La campagna sarebbe iniziata con la compromissione di un ambiente CI/CD collegato ad Aqua Security, la società che mantiene Trivy. Gli aggressori avrebbero sfruttato credenziali non completamente revocate durante una precedente rotazione e ottenuto token GitHub con privilegi sufficienti per modificare i riferimenti usati dalle GitHub Actions. Tra il 19 e il 20 marzo, diversi tag di trivy-action e setup-trivy furono spostati verso commit contenenti codice malevolo. Il nome della dipendenza restava invariato, ma il workflow eseguiva un contenuto diverso da quello atteso.

Il payload cercava segreti disponibili sul runner, tra cui chiavi SSH, token cloud, credenziali Kubernetes e file .env. Una parte del codice simulava il comportamento normale dello scanner, così la pipeline poteva produrre risultati corretti mentre i dati venivano esfiltrati. Un singolo aggiornamento poteva raggiungere molti repository, senza compromettere ogni vittima separatamente.

Le credenziali rubate permisero di ampliare l’operazione. Il 23 marzo furono colpite le GitHub Actions di Checkmarx KICS e AST, mentre il giorno successivo comparvero su PyPI le versioni malevole 1.82.7 e 1.82.8 di LiteLLM. Il progetto funziona come gateway tra applicazioni e provider di modelli linguistici, quindi può contenere token cloud, accessi a repository e segreti associati a infrastrutture AI.

Le contromisure devono partire dalla build

Il caso dimostra che rimuovere il pacchetto infetto non basta. Una credenziale copiata durante l’esecuzione può restare valida dopo la pulizia del runner e consentire accessi successivi contro un’organizzazione diversa. La risposta deve comprendere l’inventario dei segreti esposti, la rigenerazione di token e chiavi, l’analisi dei log e la verifica delle operazioni effettuate durante la compromissione.

La prima difesa consiste nel ridurre i privilegi dei workflow e limitare i segreti ai job che ne hanno bisogno. I token permanenti dovrebbero essere sostituiti da credenziali temporanee e federazione delle identità. Runner effimeri e isolati riducono inoltre la possibilità di persistenza o di accesso alle risorse interne.

Le dipendenze dovrebbero essere fissate a commit SHA immutabili, non a tag modificabili. È utile proteggere branch e tag, sottoporre gli aggiornamenti a revisione e verificare gli hash degli artefatti.