How 18 packages got backdoored
At 20:24 UTC on July 8 2026, a wallet that loaded the newest build of @injectivelabs/sdk-ts quietly handed its seed phrase to an attacker. The first malicious commit had just landed, and it stayed live for roughly 49 minutes before anyone noticed.
The attackers did not brute their way in. They used a long-established, trusted contributor's GitHub account to push three commits that backdoored the SDK at version 1.20.21, plus 17 dependent packages pinned to that exact version. Eighteen packages in total carried the same poison. The backdoor hooked PrivateKey.fromMnemonic() and PrivateKey.fromHex(), so it exfiltrated BIP-39 seed phrases and private keys the instant a wallet initialised.
About 310 downloads occurred before the maintainer caught it, reverted, and shipped a clean 1.20.23. Injective Labs says no user funds were lost. The malicious release was deprecated on npm rather than removed, so it still sits in the registry as a warning marker.
The trusted pipeline was the weak point
The safeguard was the delivery mechanism. The malicious version travelled through Injective Labs' own trusted-publisher pipeline on npm, the OIDC path built precisely to remove the risk of a stolen publishing token.
That is the uncomfortable part. OIDC trusted publishing means a package can be released without any long-lived npm token to steal, which is a real security win. But it also means a compromised human contributor account plus an automated build turns that trust into the attack path. There was no token to leak because the pipeline itself did the signing, and the pipeline trusted the account that GitHub said was legitimate.
What to check in your own dependencies
The lesson here is general, not crypto-specific. Any owner who ships software inherits this exact exposure through transitive dependencies, the packages your packages depend on that you never chose to install directly.
Pin your transitive dependencies to known-good versions and scan them, so a mid-stream swap at a pinned version shows up as a change rather than sliding through. Treat trusted-publisher automation as a reduction of one risk, not the removal of all of them, because the human-account compromise route stays open. And rotate any secret, key, or credential that passed through a build you now suspect, on the assumption it was seen.
Read next: Progress tells ShareFile users to pull the plug | A Defender Flaw Lets a Local User Take Over the PC
