Hvordan 18 pakker fik en bagdør
Klokken 20:24 UTC den 8. juli 2026 afleverede en wallet, der indlæste den nyeste build af @injectivelabs/sdk-ts, stille sin seed-sætning til en angriber. Den første ondsindede commit var netop landet og forblev aktiv i cirka 49 minutter, før nogen bemærkede det.
Angriberne brød sig ikke ind med magt. De brugte GitHub-kontoen fra en veletableret, betroet bidragyder til at pushe tre commits, der lagde en bagdør i SDK'et i version 1.20.21, plus 17 afhængige pakker låst til netop den version. Atten pakker i alt bar den samme gift. Bagdøren kaprede PrivateKey.fromMnemonic() og PrivateKey.fromHex(), så den exfiltrerede BIP-39-seed-sætninger og private nøgler i det øjeblik, en wallet startede.
Der skete omkring 310 downloads, før vedligeholderen opdagede det, rullede tilbage og udgav en ren 1.20.23. Injective Labs siger, at ingen brugermidler gik tabt. Den ondsindede version blev markeret som forældet på npm i stedet for fjernet, så den ligger stadig i registret som et advarselsmærke.
Den betroede pipeline var det svage punkt
Værnet var selve leveringsmekanismen. Den ondsindede version rejste gennem Injective Labs' egen betroede udgiverpipeline på npm, OIDC-stien, der er bygget netop for at fjerne risikoen for en stjålet udgivelses-token.
Det er den ubehagelige del. OIDC-betroet udgivelse betyder, at en pakke kan udgives uden nogen langlivet npm-token at stjæle, hvilket er en reel sikkerhedsgevinst. Men det betyder også, at en kompromitteret menneskelig konto plus en automatiseret build gør den tillid til angrebsvejen. Der var ingen token at lække, fordi pipelinen selv stod for signeringen, og pipelinen stolede på den konto, som GitHub erklærede legitim.
Hvad du bør tjekke i dine egne afhængigheder
Læren her er generel, ikke krypto-specifik. Enhver ansvarlig, der udgiver software, arver netop denne eksponering gennem transitive afhængigheder, de pakker, dine pakker afhænger af, og som du aldrig selv har valgt at installere direkte.
Lås dine transitive afhængigheder til kendte gode versioner og scan dem, så en udskiftning midt i forløbet på en låst version fremstår som en ændring i stedet for at glide igennem. Behandl automatisering af den betroede udgiver som en reduktion af én risiko, ikke fjernelsen af dem alle, for vejen via den kompromitterede menneskelige konto står stadig åben. Og roter enhver hemmelighed, nøgle eller legitimation, der passerede en build, du nu mistænker, ud fra en antagelse om, at den er blevet set.
Læs videre: Progress beder ShareFile-kunder slukke serveren | En Defender-fejl giver en bruger fuld kontrol
