The Pulse
La versione npm malevola di Tensorlake ha preso di mira le credenziali degli sviluppatori
Tensorlake afferma che un account di un manutentore compromesso ha pubblicato la versione npm malevola 0.5.144 l’8 ottobre 2026. Il payload eseguito durante l’installazione prendeva di mira le credenziali degli sviluppatori e la configurazi
AI.info Team · Scritto con l’IA ·
Per circa 1 ora e 40 minuti, l’8 ottobre, npm ha ospitato una versione malevola dell’SDK TypeScript di Tensorlake. La versione 0.5.144 è stata disponibile tra le 01:12 e le 02:54 UTC dopo che un aggressore ha usato l’account compromesso di un manutentore per inviare codice al repository di Tensorlake e pubblicare la versione tramite il suo processo di rilascio, ha dichiarato l’azienda. La versione aveva persino un’attestazione di provenienza npm valida, ma questo non la rendeva autorizzata.
«Questa versione non era una pubblicazione autorizzata di Tensorlake.»
Avviso di sicurezza di Tensorlake
L’avviso indica la versione npm come distribuzione interessata e afferma che i pacchetti PyPI e crates.io di Tensorlake, insieme al suo strumento a riga di comando, non sono stati coinvolti. Elenca la versione 0.5.144 per il pacchetto principale e per i pacchetti nativi specifici delle diverse piattaforme. Tensorlake ha inoltre dichiarato di non aver rilevato alcun utilizzo di quella versione nei dati sull’uso dell’SDK che monitora.
La versione 0.5.144 veniva eseguita durante l’installazione
Il pacchetto compromesso usava un hook preinstall per eseguire un payload JavaScript offuscato: il codice poteva quindi essere eseguito durante l’installazione, senza aspettare che un’applicazione importasse l’SDK. Secondo l’analisi di Sonatype, il programma di installazione avviava il payload tramite Bun e poteva scaricare Bun 1.3.13 se non era già presente. La raccolta di credenziali effettuata dal codice aveva ben poco a che fare con le funzioni dichiarate dell’SDK relative a sandbox, repository e servizi cloud.
Secondo l’avviso di Tensorlake, il payload prendeva di mira token di GitHub e npm, credenziali di AWS e Google Cloud, token di Kubernetes e Vault, chiavi SSH e GPG, file di ambiente, password salvate nei browser, portafogli di criptovalute e configurazioni degli strumenti di IA e di MCP. L’analisi di Sonatype cita file associati a Claude, Cursor, Kiro, Codex, Gemini e Windsurf. Secondo Sonatype, il payload interrogava inoltre periodicamente un canale di comando e valutava codice JavaScript fornito da remoto.
Gli accessi rubati potevano raggiungere altri repository
L’avviso afferma che il malware usava i token rubati per ripubblicarsi in altri pacchetti npm e repository su cui la vittima aveva permessi di scrittura. Sonatype ha individuato codice in grado di creare un repository GitHub pubblico e di salvarvi i dati raccolti con un commit; uno dei percorsi di esecuzione poteva includere un token GitHub rubato nei dati caricati e nel messaggio del commit. L’analisi ha inoltre rilevato una logica per aggiungere file .claude e .vscode ai repository accessibili, con la possibilità di esporre altri sviluppatori che li avrebbero usati in seguito.
L’avviso descrive un servizio persistente chiamato gh-token-monitor che elimina la directory home dell’utente se il token GitHub rubato viene revocato. Tensorlake afferma che gli utenti dovrebbero rimuovere il servizio prima di revocare i token. Questo comportamento distruttivo rende più delicata la risposta all’incidente: limitarsi a sostituire prima le credenziali potrebbe attivare la condizione che il malware è stato progettato per sfruttare.
La portata confermata resta più limitata delle capacità del payload
Sonatype ha rilevato che l’hook di installazione si interrompe quando individua diversi specifici indicatori di ambiente CI, tra cui alcune variabili di GitHub Actions e GitLab CI. Questo comportamento non dimostra che i sistemi CI fossero esclusi dagli obiettivi dell’aggressore, né che tutti gli ambienti CI siano stati risparmiati. L’avviso di Tensorlake invita i team a considerare compromessa una macchina o un sistema CI se la versione è stata installata con gli script abilitati.
Né l’avviso né l’analisi di Sonatype confermano che i dati raccolti siano stati pubblicati, che i repository siano stati modificati o che i sistemi a valle siano stati coinvolti. La possibilità che ciò sia accaduto non è una prova che sia successo. Sonatype afferma che proseguirà le indagini man mano che verranno confermati ulteriori componenti e conseguenze.
Tensorlake consiglia di controllare i lockfile e i log di build
Tensorlake consiglia di verificare se tra le dipendenze dei progetti figurano tensorlake@0.5.144 e pacchetti tensorlake-native-* specifici delle diverse piattaforme nella stessa versione, e di esaminare i registri delle build per individuare installazioni avvenute tra le 01:12 e le 02:54 UTC dell’8 ottobre. L’avviso indica come non interessate la versione 0.5.143 e quelle precedenti e raccomanda di tornare alla 0.5.143 oppure di passare alla 0.5.145 una volta pubblicata, come specificato al momento dell’avviso.
Per i sistemi su cui è stata eseguita la versione malevola, l’azienda raccomanda di scollegare la macchina, rimuovere il servizio di monitoraggio dei token e poi sostituire le credenziali accessibili usando un’altra macchina non compromessa. Consiglia inoltre di controllare i pacchetti npm e i repository che quelle credenziali consentivano di pubblicare o modificare, quindi di ricostruire la macchina interessata a partire da un’immagine attendibile. La sola rimozione del pacchetto non può revocare le credenziali che potrebbe aver già letto.