Hoe 18 pakketten een achterdeur kregen
Om 20:24 UTC op 8 juli 2026 gaf een wallet die de nieuwste build van @injectivelabs/sdk-ts laadde stilletjes zijn seed-zin door aan een aanvaller. De eerste kwaadaardige commit was net binnengekomen en bleef ongeveer 49 minuten actief voordat iemand het opmerkte.
De aanvallers braken niet met geweld in. Ze gebruikten het GitHub-account van een langgevestigde, vertrouwde bijdrager om drie commits te pushen die het SDK op versie 1.20.21 van een achterdeur voorzagen, plus 17 afhankelijke pakketten die op precies die versie waren vastgezet. Achttien pakketten in totaal droegen hetzelfde gif. De achterdeur kaapte PrivateKey.fromMnemonic() en PrivateKey.fromHex(), zodat het BIP-39-seed-zinnen en privésleutels wegsluisde op het moment dat een wallet startte.
Er waren ongeveer 310 downloads voordat de beheerder het opmerkte, terugdraaide en een schone 1.20.23 uitbracht. Injective Labs zegt dat er geen gebruikersgelden verloren zijn gegaan. De kwaadaardige versie is op npm als verouderd gemarkeerd in plaats van verwijderd, dus die staat nog in het register als waarschuwingssignaal.
De vertrouwde pijplijn was de zwakke plek
De beveiliging was het leveringsmechanisme. De kwaadaardige versie reisde via de eigen vertrouwde uitgeverspijplijn van Injective Labs op npm, het OIDC-pad dat precies is gebouwd om het risico van een gestolen publicatietoken weg te nemen.
Dat is het ongemakkelijke deel. OIDC-vertrouwde publicatie betekent dat een pakket kan worden uitgebracht zonder enig langlevend npm-token om te stelen, wat een echte veiligheidswinst is. Maar het betekent ook dat een gecompromitteerd menselijk account plus een geautomatiseerde build dat vertrouwen in de aanvalsroute verandert. Er was geen token om te lekken omdat de pijplijn zelf de ondertekening deed, en de pijplijn vertrouwde het account dat GitHub legitiem verklaarde.
Wat te controleren in je eigen afhankelijkheden
De les hier is algemeen, niet crypto-specifiek. Elke verantwoordelijke die software uitlevert erft precies dezelfde blootstelling via transitieve afhankelijkheden, de pakketten waarvan jouw pakketten afhangen en die je nooit rechtstreeks hebt gekozen te installeren.
Zet je transitieve afhankelijkheden vast op bekende, betrouwbare versies en scan ze, zodat een tussentijdse wissel op een vastgezette versie opvalt als een wijziging in plaats van erdoorheen te glippen. Behandel automatisering van de vertrouwde uitgever als het verminderen van één risico, niet als het wegnemen van alle, want de route via het gecompromitteerde menselijke account blijft open. En roteer elk geheim, elke sleutel of elk inloggegeven dat door een nu verdachte build ging, in de veronderstelling dat het is gezien.
Lees hierna: Progress: ShareFile-klanten moeten de stekker eruit | Een Defender-lek geeft een gebruiker volledige controle
