Come 18 pacchetti hanno preso una backdoor
Alle 20:24 UTC dell'8 luglio 2026 un portafoglio che ha caricato l'ultima build di @injectivelabs/sdk-ts ha consegnato in silenzio la sua frase seed a un aggressore. Il primo commit malevolo era appena arrivato ed è rimasto attivo per circa 49 minuti prima che qualcuno se ne accorgesse.
Gli aggressori non sono entrati con la forza. Hanno usato l'account GitHub di un collaboratore fidato e già affermato per inviare tre commit che hanno messo una backdoor nell'SDK alla versione 1.20.21, più 17 pacchetti dipendenti fissati a quella versione esatta. Diciotto pacchetti in tutto portavano lo stesso veleno. La backdoor agganciava PrivateKey.fromMnemonic() e PrivateKey.fromHex(), così esfiltrava frasi seed BIP-39 e chiavi private nell'istante in cui un portafoglio si avviava.
Ci sono stati circa 310 download prima che il manutentore se ne accorgesse, annullasse e rilasciasse una versione pulita 1.20.23. Injective Labs afferma che non sono andati persi fondi degli utenti. La versione malevola è stata contrassegnata come obsoleta su npm anziché rimossa, perciò resta nel registro come segnale di avviso.
La pipeline fidata era il punto debole
La salvaguardia era il meccanismo di consegna. La versione malevola è passata dalla pipeline di pubblicazione fidata di Injective Labs su npm, il percorso OIDC costruito proprio per eliminare il rischio di un token di pubblicazione rubato.
Questa è la parte scomoda. La pubblicazione fidata OIDC significa che un pacchetto può essere rilasciato senza alcun token npm di lunga durata da rubare, ed è un vantaggio di sicurezza reale. Ma significa anche che un account umano compromesso più una build automatizzata trasformano quella fiducia nel percorso di attacco. Non c'era alcun token da trafugare perché era la pipeline stessa a firmare, e la pipeline si fidava dell'account che GitHub dichiarava legittimo.
Cosa controllare nelle tue dipendenze
La lezione qui è generale, non specifica delle criptovalute. Qualsiasi responsabile che rilascia software eredita questa stessa esposizione tramite le dipendenze transitive, i pacchetti da cui dipendono i tuoi pacchetti e che non hai mai scelto di installare direttamente.
Fissa le tue dipendenze transitive a versioni note come sicure e scansionale, così uno scambio a metà strada su una versione fissata appare come una modifica anziché passare inosservato. Tratta l'automazione del publisher fidato come la riduzione di un rischio, non l'eliminazione di tutti, perché la via dell'account umano compromesso resta aperta. E ruota ogni segreto, chiave o credenziale passata da una build che ora sospetti, partendo dal presupposto che sia stata vista.
Da leggere ora: Progress: clienti ShareFile devono spegnere il server | Un difetto di Defender dà il pieno controllo del PC
