Attackers Hijacked Injective Labs' GitHub to Slip Wallet-Stealing Code Into npm
A tampered @injectivelabs/sdk-ts release quietly siphoned crypto wallet keys and seed phrases from developers who installed it.
Key points
- Unknown attackers broke into Injective Labs' GitHub account and published a poisoned version of its software toolkit, @injectivelabs/sdk-ts version 1.20.21, on the npm registry.
- The rogue package hid inside fake telemetry code that quietly copied cryptocurrency wallet private keys and seed phrases off victims' machines.
- npm is the world's largest catalogue of ready-made JavaScript building blocks, used by millions of developers who trust maintainers to ship clean code.
- Anyone who installed the poisoned version should assume any wallet touched by that machine is burned and move funds to a fresh wallet immediately.
- The attack fits a pattern of supply-chain hits on crypto-adjacent open-source projects throughout 2024 and 2025.
Someone got into the GitHub account that Injective Labs uses to build its developer toolkit. They then used that access to push a malicious update to npm, the public software library where JavaScript developers download building blocks for their apps.
The tampered release is @injectivelabs/sdk-ts version 1.20.21. Injective is a blockchain project focused on financial applications, and its SDK (short for software development kit, meaning a bundle of code other developers plug into their own apps) is widely used by teams building on that chain.
The malicious code was disguised as telemetry, the harmless-looking bit of software that normally just reports crash data or usage stats back to the maker. In this case the telemetry was a decoy. It hunted for cryptocurrency wallet private keys and mnemonic seed phrases on the developer's machine and sent them to the attackers.
A private key or seed phrase is the master password to a crypto wallet. Whoever holds it owns the coins. There is no bank to call and no reversal.
According to reporting by The Hacker News, which first surfaced the incident, the poisoned version sat on npm long enough to be pulled down by anyone building against the SDK during that window.
What should developers and their users do right now?
If you or your team installed @injectivelabs/sdk-ts 1.20.21, treat the machine as untrusted. Any wallet whose keys or seed phrase were ever entered, stored, or generated on that machine should be considered stolen, even if funds have not moved yet. Move assets to a new wallet created on a clean device.
Check your package-lock.json and yarn.lock files (these are the receipts that record exactly which versions were pulled in) for that specific version string. Downgrade to a known-good earlier release or upgrade to whatever Injective marks as clean once the project confirms a safe version.
Rotate any credentials, API tokens, and SSH keys that lived on the affected machine. Wallet theft is the headline, but attackers with code execution rarely stop at one payload.
How did the attackers pull it off?
The short answer: they got into GitHub. The longer answer is not yet public. A hijack like this usually starts one of a few ways. A maintainer's GitHub account is taken over through a stolen password or a session cookie lifted by infostealer malware. Or a personal access token with publish rights leaks into a public repo, a CI log, or a developer laptop that got popped earlier.
Once inside, the attacker only needs to tag a new release. The npm registry trusts whatever the linked GitHub project tells it to publish. Downstream developers then pull the update automatically the next time they run an install command.
This is the same playbook seen in earlier crypto-focused supply-chain attacks, including the Ledger Connect Kit incident in December 2023 and the string of poisoned Solana and Ethereum helper libraries throughout 2024. The target is always the same: developers who touch wallet code, because their machines and their users' machines are where the money lives.
Injective Labs has not yet published a full post-mortem naming the initial access vector. Until it does, assume the compromise window is wider than the single bad version, and audit anything that account touched.
