Published on gastropod.io - 07-17-2026

When Your Own CI Pipeline Publishes the Backdoor: Inside the Injective SDK Wallet-Key Theft

Tags: vulnerability intelligence, software supply chain security, npm, credential-theft, crypto

On July 8, 2026, someone with write access to a trusted maintainer's GitHub account slipped a few lines into the Injective Labs TypeScript SDK, @injectivelabs/sdk-ts. The change hooked into PrivateKey.fromMnemonic(), the function every wallet, DEX frontend, and trading bot built on Injective calls the moment it needs to generate or load a wallet. Any seed phrase or private key that passed through it got quietly copied and sent off to an endpoint dressed up to look like Injective's own infrastructure.

The unsettling part isn't the payload itself, it's how it got published. There was no stolen npm token to revoke, no compromised registry account to lock. The commit landed on the repository's main branch under the identity of an existing, trusted contributor, and the project's own GitHub Actions publishing pipeline, OIDC trusted-publisher setup and provenance attestation included, built and shipped it exactly as it was told to. From npm's point of view, this looked like a normal, verifiably-provenanced release from a legitimate source.

Eighteen packages in the @injectivelabs scope went out carrying the version bump, though only sdk-ts itself held the malicious logic. The other seventeen simply pinned an exact dependency on the poisoned version and dragged it along for the ride. The window was short, Injective caught and reverted it in under twenty minutes, and by most accounts no funds were actually lost. But roughly 87 downstream packages depend on sdk-ts, and anyone who installed or had a cached copy of that version during the exposure window needs to treat every wallet secret it touched as burned.

More detail on the timeline and exact commit hashes is in BleepingComputer's writeup, and SC Media has a shorter version if you just want the summary.

This is exactly the kind of incident that a simple "is this package fake" check won't catch, because the artifact really was published by the real project through the real pipeline. What catches it is knowing, the second a new version lands, precisely which of your own services already pulled it and when, so "was I exposed" turns into a lookup instead of an afternoon of grepping build logs and pinging every team to check their lockfiles by hand. That's why we built the blast-radius and per-pull audit trail into Gastropod. If interested you can see how the identity and attribution pieces fit together on the product page.