Dertien npm-packages, 48 seconden, één nep wallet SDK

Een gecoördineerde aanval op de npm-registry dumpte in slechts 48 seconden 13 vervalste wallet SDK-packages in de stijl van Coinbase, wat laat zien hoe snel kwaadaardige code zich kan voordoen als vertrouwde tooling. Ontwikkelaars die een package installeren op basis van alleen een bekende naam, kunnen onbedoeld een nep SDK in hun apps injecteren.

De packages verschenen tussen 04:54:59 en 04:55:48 UTC op 7 september 2026. Namen als cb-wallet-http en scw-core doen denken aan de officiële @coinbase/wallet-sdk namespace. In plaats van typosquatting gebruikten de aanvallers bekende tekstreeksen als prefix, in de hoop dat een aanbeveling van een collega of een forumbericht gebruikers van hun legitimiteit zou overtuigen.

Alle 13 releases deelden dezelfde minimale configuratie: versie 0.0.1-security, een lege lijst met maintainers en de standaard npm-metadata die direct na publicatie wordt getoond. De identieke opzet wijst op een enkel script dat de packages genereerde, een kenmerk van automatisering in plaats van handmatige inspanning.

Het open publicatiemodel van npm stelt iedereen in staat om een package te uploaden zonder voorafgaande controle, wat dit soort aanvallen mogelijk maakt. Eerdere supply-chain incidenten hebben aangetoond dat zodra kwaadaardige code in een dependency tree terechtkomt, deze wordt uitgevoerd op elke machine die het installeert.

NPM heeft de daders nog niet geïdentificeerd en heeft niet uitgelegd hoe de code zich buiten de initiële uploads heeft verspreid. Het is ook onduidelijk of de aanvallers specifiek op Coinbase-gebruikers mikten of de registry simpelweg overspoelden met geloofwaardig klinkende namen, in de hoop dat sommige zouden worden overgenomen.

Wat ontwikkelaars nu kunnen doen

  • Controleer de publisher van een package voordat je deze toevoegt; officiële SDK's vallen onder geverifieerde organization scopes.
  • Gebruik tools die dependencies scannen op bekende kwaadaardige signatures.
  • Leg exacte versies vast in lockfiles en vermijd het binnenhalen van nieuw gepubliceerde packages zonder controle.
  • Geef de voorkeur aan registries die twee-factor-authenticatie vereisen voor maintainers.

Waar op te letten

  • Of npm de controle aanscherpt voor packages die bekende merken nabootsen.
  • Community-gestuurde blacklists die namen die zich voordoen als anderen markeren.
  • Updates van security researchers over eventuele actieve exploitatie van de 13 nep SDK's.

Dit incident bewijst dat een bekende naam geen enkele garantie biedt voor veiligheid. Waakzaamheid en verificatie blijven de sterkste verdedigingsmiddelen tegen supply-chain aanvallen in het open-source ecosysteem.