Injective SDK compromised: wallet stealer hidden in 18 npm packages

A compromised GitHub account belonging to a legitimate contributor to the Injective Labs SDK was used to publish a malicious version of @injectivelabs/sdk-ts to npm. The attack was detected and reported by Socket, OX Security, and StepSecurity.

The malicious version is 1.20.21. A clean release, 1.20.23, followed quickly after the legitimate account owner detected the compromise and reverted the changes. The malicious version was downloaded 310 times before it was deprecated. It has not been removed from the registry.

What the malware does#

The wallet stealer does not activate on installation. It waits until the application calls SDK functions that generate or import wallet keys. At that point it captures the full mnemonic seed phrase and private key, encodes them in base64, and exfiltrates them via an HTTP POST request routed through Injective Labs' own public infrastructure to make the traffic look legitimate. Keys and mnemonics are queued for two seconds and then bundled into a single request header before transmission.

Developers who installed or updated to 1.20.21 and used wallet functions should rotate all secrets from a clean machine and transfer cryptocurrency holdings to freshly generated wallets.

What Attestd returns#

curl "https://api.attestd.io/v1/check?product=%40injectivelabs%2Fsdk-ts&version=1.20.21" \
  -H "Authorization: Bearer $ATTESTD_API_KEY"

{
  "product": "@injectivelabs/sdk-ts",
  "version": "1.20.21",
  "supported": true,
  "risk_state": "none",
  "supply_chain_monitored": true,
  "supply_chain": {
    "compromised": true,
    "sources": ["agent", "npm_deprecation", "osv", "registry"],
    "malware_type": "wallet_stealer",
    "description": "Compromised contributor GitHub account. Malware activates on wallet key generation/import, exfiltrates mnemonics and private keys via HTTP POST to Injective public endpoint.",
    "advisory_url": "https://socket.dev/blog/compromised-injective-sdk-npm-package",
    "compromised_at": "2026-06-08T20:59:00Z",
    "removed_at": null
  }
}

risk_state: none because there is no CVE here. The SDK itself is clean code. The compromise is in the supply chain, not the vulnerability record, which is why the two signals exist independently. An autonomous system checking only CVE state would pass this version clean.

removed_at: null reflects the current registry state. The package is deprecated, not removed. Depending on lockfile resolution behavior, some toolchains may still resolve to it.

The clean version:

curl "https://api.attestd.io/v1/check?product=%40injectivelabs%2Fsdk-ts&version=1.20.23" \
  -H "Authorization: Bearer $ATTESTD_API_KEY"

{
  "product": "@injectivelabs/sdk-ts",
  "version": "1.20.23",
  "supported": true,
  "supply_chain_monitored": true,
  "supply_chain": {
    "compromised": false,
    "sources": []
  }
}

The fan-out#

The attacker published 1.20.21 across 17 additional packages in the @injectivelabs scope, pinning all of them to the compromised SDK version. Three samples from the sibling packages:

All three return supply_chain.compromised: true. The 87 direct npm dependents of the SDK package had a cumulative download count of approximately 112,000 according to OX Security.

Coverage#

@injectivelabs/sdk-ts and the sibling packages sampled above are covered and returning accurate compromise signals as of July 9, 2026. The full set of 18 affected packages in the @injectivelabs scope is being reviewed for watchlist coverage.

API documentation: attestd.io/docs. Detection ledger: github.com/attestd-io/detection-ledger. Machine speed thesis: attestd.io/thesis.