Attackers Hijacked Injective Labs' GitHub to Slip Wallet-Stealing Code Into npm

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, 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 (a 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 kind of software that normally reports crash data or usage stats back to the maker. Here it 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's no bank to call and no reversal.

According to The Hacker News, which first surfaced the incident, the poisoned version sat on npm long enough to be pulled by anyone building against the SDK during that window. We covered an earlier stage of this same compromise on 9 July 2026 in "Poisoned Injective SDK on npm quietly stole crypto wallet keys for hours".

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 on that machine should be considered stolen, even if funds haven't moved yet. Move assets to a new wallet created on a clean device.

Check your package-lock.json and yarn.lock files (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 API tokens and SSH keys that lived on the affected machine. Attackers with code execution rarely stop at one payload.

How did the attackers pull it off?

They got into GitHub, though the exact method isn't yet public. A hijack like this typically starts with a maintainer's account taken over through a stolen password or a session cookie lifted by infostealer malware, or a personal access token with publish rights that leaked onto an exposed system.

Once inside, the attacker only needs to tag a new release. The npm registry trusts whatever the linked GitHub project tells it to publish, and downstream developers pull the update automatically the next time they run an install.

This is the same playbook seen in the Ledger Connect Kit incident in December 2023 and the string of poisoned Solana and Ethereum helper libraries throughout 2024. The target is always developers who touch wallet code, because their machines are where the money lives. Worth noting: npm's own direction has been moving against exactly this class of attack. Our June reporting on npm 12 disabling install scripts by default showed how that default change is meant to blunt the mechanism attackers rely on here, though a compromised publish step bypasses it entirely.

Injective Labs hasn't published a 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.