Someone Backdoored a Crypto SDK to Steal Wallet Keys on Tuesday. Our Deny-List Was Already Blocking the Exact Version — and No Human Touched It.
- Patrick Duggan
- 6 minutes ago
- 3 min read
Yesterday we told you about the jscrambler npm compromise and made a point of it: we caught the indicators, hand-ingested them, and the free check-package tool we shipped could then block the stealer for any AI agent that asked. That was us doing the work by hand. Today the same class of attack hit a different target, and this time we did not have to lift a finger. The deny-list already had it. That is the version of this that actually scales, so it is worth showing you.
What got hit
The target was @injectivelabs/sdk-ts — the official TypeScript SDK for the Injective blockchain, a package with around fifty thousand weekly downloads, used by people building crypto wallets, trading bots, decentralized exchanges, and DeFi apps. On July 8, an attacker who had compromised a GitHub account belonging to an established, trusted contributor to the project pushed malicious commits into the official repository and cut a poisoned release: version 1.20.21.
The tradecraft is worth understanding because it is quiet. The malware does not fire on install, which is where most scanners and most humans are looking. It waits. It only activates when a developer calls the SDK functions that generate or import wallet keys — exactly the moment the most valuable secret in the whole system is in memory. At that point it grabs the full mnemonic seed phrase and the private key, base64-encodes them, and exfiltrates them disguised as ordinary telemetry. If you build a wallet with the poisoned SDK, the keys to that wallet walk out the door the first time you use them.
And it spread sideways: the attacker published 1.20.21 across seventeen additional @injectivelabs-scoped packages that pin the malicious SDK version, so developers who never installed the SDK directly could still inherit it transitively. To Injective's credit, they caught and resolved it fast — the bad version was deprecated, and they report resolving the compromise in under an hour with no confirmed user losses. It was downloaded 310 times before deprecation. Credit for the detection goes to Socket, Ox Security, and StepSecurity, whose scanners flagged it.
The receipt
Here is the part that matters to us, and we checked it live before writing this sentence.
We asked our own free check-package tool about the poisoned version and the fix. @injectivelabs/sdk-ts at version 1.20.21 comes back malicious, verdict block. The clean version, 1.20.23, comes back verdict review — not blocked, because it is version-aware and knows the specific poisoned release is the problem, not the package as a whole. It tells you to verify your version rather than punishing the fix.
Now the part that is different from jscrambler. With jscrambler, we hand-ingested the indicators. With Injective, we did nothing. Our automated OSV malicious-package feed — a daily cron that pulls curated, named-malicious packages into our deny-list — had already picked up the poisoned Injective release and folded it in. So an AI coding agent, or a CI build gate, or anyone pulling our package feed, was protected against this specific compromise without a single human at DugganUSA touching it. A real crypto-wallet-stealing backdoor landed on Tuesday, and by the weekend the guardrail was already refusing it, automatically, and correctly clearing the fix.
That is the whole thesis made concrete. The value is not that a person here is fast. The value is that the machine is always on. The gap between "a supply-chain attack exists" and "your agent refuses it" is supposed to close on its own, and here it did.
What to actually do
If you build anything on Injective, or on any package that transitively pulled @injectivelabs/sdk-ts, check your lockfile for version 1.20.21 across the scoped packages, and if you find it, assume any wallet keys generated or imported while it was installed are compromised — rotate them and move the funds. Pin to 1.20.23 or later. And the general lesson, held to about ninety-five percent because no deny-list is the whole universe of bad packages: install-time is not the only danger surface anymore. This malware slept until you called the exact function that touched your secret. The defense that works is one that checks the dependency before it is ever trusted — at the agent, at the build, before the code runs.
The tool that does it is free, takes one URL, and needs no key. It blocked this one before we woke up. That is the point of building it.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.