Compromised Injective SDK sends wallet keys through fake telemetry
According to Aikido, a compromised release of Injective’s JavaScript SDK quietly stole wallet private keys and seed phrases, then hid the theft behind routine-looking telemetry traffic.
- Package hit: @injectivelabs/sdk-ts v1.20.21
- Secrets exposed: private keys and recovery phrases
- Scope: 17 related Injective npm packages
- Exposure: 310 downloads before removal
- Core lesson: supply-chain attacks are after developer trust, not just user wallets
Aikido said the malicious code was introduced after a developer’s GitHub account was compromised, with suspicious commits beginning on June 8, 2026. The altered release then spread through related packages under the @injectivelabs npm scope, turning one poisoned dependency into a wider problem for anyone building with the toolkit.
This is the part of crypto security people still underestimate: attackers do not always need to break the blockchain. Sometimes they just need to hijack the tools developers already trust.
The affected package, @injectivelabs/sdk-ts version 1.20.21, had about 50, 000 weekly downloads. Aikido said the malicious version was downloaded 310 times before it was pulled. That is not a giant number in the abstract, but for a package that handles wallet operations, the damage potential is obvious. One bad dependency can fan out fast through wallets, bots, dashboards, and apps.
The malware was built to be sneaky. Aikido said it intercepted wallet key-generation functions at runtime, meaning the code waited until a wallet was being created, then copied the secret as it was generated. It captured private keys and mnemonic recovery phrases, encoded the data, and sent it off through fake telemetry to a web address shaped to resemble Injective infrastructure: testnet[.]archival[.]chain[.]grpc-web[.]injective[.]network.
Telemetry normally refers to routine diagnostic data software sends back for monitoring or debugging. Here, it was used as camouflage for exfiltration, which is just the polite security term for sneaking data out of a system.
“Any keys or mnemonics passed through affected packages should be treated as compromised.”, Aikido
That warning is not dramatic overkill. In crypto, a leaked private key or seed phrase is usually enough to take control of a wallet without asking anyone’s permission. No password reset. No help desk. No mercy.
The technical trick matters too. Aikido said the malicious code lived inside distributed package files rather than an install-time script. In plain English: it did not rely on a noisy postinstall hook that many scanners already watch for. It sat quietly in the code that applications load during normal use, then triggered when a wallet secret was derived.
Aikido also said the malicious release was published on June 8, 2026, reverted at 23:18, and replaced with a clean version at 23:48. That quick response likely limited the damage. Even so, the report said the campaign was not yet fully contained at the time of reporting, with the malicious npm release deprecated but still present in some form and release artifacts still available.
Injective CEO Eric Chen said the affected npm releases had been deprecated and the issue was fixed, and he added that no funds on the Injective network were at risk. That narrower point makes sense: this was a compromise of developer tooling, not a breach of blockchain consensus. But that does not make the situation harmless. The chain can be fine while wallets, test environments, and downstream apps are exposed.
The scope also extended beyond a single package. Aikido identified 17 affected packages under the Injective scope, including wallet, utility, and network components. The list included:
- @injectivelabs/sdk-ts
- @injectivelabs/utils
- @injectivelabs/networks
- @injectivelabs/ts-types
- @injectivelabs/exceptions
- @injectivelabs/wallet-base
- @injectivelabs/wallet-core
- @injectivelabs/wallet-cosmos
- @injectivelabs/wallet-private-key
- @injectivelabs/wallet-evm
- @injectivelabs/wallet-trezor
- @injectivelabs/wallet-cosmostation
- @injectivelabs/wallet-ledger
- @injectivelabs/wallet-wallet-connect
- @injectivelabs/wallet-magic
- @injectivelabs/wallet-strategy
- @injectivelabs/wallet-turnkey
- @injectivelabs/wallet-cosmos-strategy
The important part is not just the number of packages. It is what that number says about modern crypto development: one compromised maintainer account can contaminate a whole dependency tree before anyone notices. Composability is powerful, but it also means trust gets reused at scale, and reused trust is exactly what attackers want to poison.
The broader threat picture is ugly for a reason. The Security Alliance said in its second-quarter threat report that attackers have increasingly used npm, GitHub, and Google to distribute malware. That fits the pattern here: GitHub account compromise leads to malicious package publication, npm becomes the delivery mechanism, and the code looks normal enough to survive casual inspection.
SEAL also said compromised machines have sometimes been used to push malicious code into a company’s own GitHub repositories. In other words, the attack surface is not just the registry or the repo. It is the whole messy human stack around it.
Recent incidents make the pattern hard to ignore. Axios npm releases were hit by a similar supply-chain attack in March. The TrapDoor campaign in May targeted developers working in crypto, DeFi, artificial intelligence and security. On May 20, GitHub disclosed unauthorized access to internal repositories after an employee device was compromised. Different incidents, same lesson: attackers keep going after developer trust because it is often easier than attacking hardened systems directly.
CertiK said wallet compromises were the costliest crypto attack method in the first half of 2026, accounting for $444 million stolen across 33 cases. That figure does not prove this Injective incident led to losses, and the available reporting does not say whether assets were actually stolen. But it does show why exposed keys should never be waved away as a theoretical problem.
For anyone using Injective tooling, the practical response is straightforward: assume any key or mnemonic that passed through the affected packages is burned, rotate secrets, and move to the clean version recommended by the maintainers, 1.20.23. If an app or wallet touched the compromised SDK, treat that exposure seriously even if there is no sign of immediate theft.
There is also a lesson here for crypto builders who still think open-source dependency management is some boring back-office chore. It is not. It is a security boundary. One compromised GitHub account can cascade into many packages. One poisoned SDK can reach production apps, staging systems, and wallet flows. That is not a theoretical footnote, it is how theft gets dressed up as normal software maintenance.
Injective itself remains an interoperable layer 1 built for DeFi and cross-chain use, but that does not shield the project’s surrounding software stack from the usual ugly realities. A blockchain can be sound while its distribution channels are a mess. Crypto purists say, “not your keys, not your coins.” Supply-chain attacks add a harsher addendum: not your dependencies, not your safety.
There is some broader project context too. DefiLlama data shows Injective’s total value locked fell 88% from a mid-2024 peak of $71 million to $8.2 million. Earlier this year, community members also approved IIP-617, accelerating reductions in new INJ issuance while keeping token burns in place. Those figures are not evidence that the SDK compromise and the tokenomics changes are connected, but they do show a project operating under real pressure. Under pressure, sloppy security hygiene is the sort of mistake nobody can afford.
Injectivelabs npm Package Hijacked: 87 Dependents Tainted
Key questions and takeaways
-
Was Injective’s blockchain hacked?
No. The compromise was in developer tooling and npm packages, not in Injective’s chain consensus or core network security. -
What did the malicious SDK steal?
According to Aikido, it captured wallet private keys and mnemonic recovery phrases, the exact secrets that can unlock a wallet. -
Why was it hard to detect?
The malware disguised exfiltration as telemetry and triggered at runtime when wallets were being created, instead of using an obvious install-time script. -
How many packages were affected?
Aikido identified 17 related Injective packages that were published at the malicious version. -
How many downloads happened before removal?
The malicious release was downloaded 310 times before it was pulled. -
Which users are at risk?
Anyone whose wallet secrets passed through the affected packages should treat those keys or mnemonics as compromised and rotate them immediately. -
What should developers do now?
Audit dependency exposure, rotate secrets, and upgrade to the clean release version 1.20.23 rather than assuming the problem ended with a package removal.
Supply-chain attacks are turning developer trust into a hunting ground. The chain may be decentralized, but the software around it still has plenty of centralized choke points, and attackers know exactly where to press.
Largest npm Supply-Chain Attack Hits Billions of Downloads
Crypto Hacks Top $17B as Private Keys and Bridges Become
Injective (INJ) Rallies 150% as Native USDC, Burns and
Further reading
A few related angles worth keeping an eye on:
