Injective's npm SDK Was Hijacked to Drain Wallets

Attackers compromised the GitHub repository behind Injective Labs' software development kit and used it to push a poisoned version to the npm registry, one built to quietly steal crypto wallet private keys and seed phrases from anyone who installed it. The malicious release, disguised with fake telemetry code that exfiltrated wallet data, went live around July 8, 2026 before being deprecated. It is a textbook software supply-chain attack, and it lands the same lesson yet again: in crypto tooling, the package you trust is the attack surface, and a single hijacked dependency can drain wallets at scale.

• Threat actors took over the Injective SDK's GitHub project and published a malicious npm package version from it.
• The poisoned build carried fake telemetry functionality that exfiltrated private keys and mnemonic seed phrases from developers' environments.
• It was released on or around July 8, 2026 and has since been deprecated on npm, but anyone who installed it during the window is exposed.
• No CVE was assigned; this is a supply-chain compromise, which existing vulnerability scanners often miss because the code itself is "new," not flagged.

How did the attack actually work?

The attackers first gained control of the Injective SDK's source repository, then published a tampered version of the package to npm so it looked like a normal update. Inside was code presented as "telemetry," a plausible thing for an SDK to include, that actually scanned the developer's environment for wallet private keys and mnemonic seed phrases and shipped them to an attacker-controlled endpoint. Because developers routinely install and update dependencies without reading every line, the malicious version could spread to CI pipelines, developer laptops, and any app that pulled it in during the exposure window. The genius and the danger are the same: it hides in the trust you already extend to your dependencies.

RelatedNightmare Eclipse Dumps 6 Unpatched Microsoft Exploits

Why are SDKs such attractive targets?

An SDK sits upstream of many applications, so poisoning one package can reach dozens or hundreds of downstream projects at once. In crypto specifically, the developer's machine often has direct access to keys, testnet wallets, and signing material, so the payoff per compromised install is enormous and instant. Unlike a stolen password, a leaked seed phrase gives permanent, irreversible control of funds. That asymmetry, low effort to poison one package versus total loss for each victim, is exactly why supply-chain attacks on crypto tooling keep happening.

Why did scanners miss it?

Traditional vulnerability tools look for known bad versions by CVE. A freshly published malicious release has no CVE, no history, and no signature to match, so it sails through. This is the structural gap in software supply-chain security: the threat is not an old flaw, it is trusted-publisher compromise. Defending against it requires provenance and integrity checks, verifying that a package was built and signed by who it claims, rather than scanning for yesterday's known vulnerabilities.

What should developers do right now?

If you pulled the Injective SDK around July 8, assume any keys or seed phrases that touched that environment are compromised and rotate them, moving funds to fresh wallets generated on a clean machine. Going forward, pin exact dependency versions and use a lockfile so you do not silently absorb a poisoned release, enable npm provenance and signature verification where available, and, most importantly, never keep production seed phrases on a machine that runs npm install. Signing should happen on hardware wallets or isolated signers, so even a fully compromised dev box has nothing worth stealing.

RelatedA CVSS 10 UniFi flaw exposes 100,000 gateways to takeover

How does this fit the broader pattern?

This is not an isolated event, it is the latest entry in a long and growing list of package-registry attacks aimed at crypto developers. The same year has seen malicious npm and PyPI packages, typosquatted libraries, and compromised maintainer accounts, all chasing the same prize: keys on a developer's machine. What makes 2026 different is the professionalization. The payloads are cleaner, the disguises more convincing, and the target selection more deliberate, with attackers specifically hunting SDKs used by wallet and DeFi teams. Treating any single incident as a one-off misses the trend. The registry itself has become a reliable, repeatable attack vector, and crypto tooling is squarely in the crosshairs because the reward per compromise is uniquely high and irreversible.

Our take

This incident is small in dollar terms compared to a big exchange hack, but it is more instructive, because it targets the layer everyone trusts and few inspect. The uncomfortable truth is that most crypto developers cannot tell you what code runs during a routine dependency install, and attackers know it. The fix is not another scanner chasing known bad versions; it is treating every dependency as untrusted by default, verifying provenance, and keeping keys out of any environment that installs packages. Until signed provenance is the norm rather than the exception, expect the poisoned-package playbook to keep working, because it keeps paying.

Original analysis by GenZTech. Reporting via The Hacker News.