An npm package that stole the private keys

A popular npm package with around 50,000 weekly downloads briefly exfiltrated users’ private keys. The official Injective SDK contained a function disguised as telemetry that harvested wallet keys and mnemonics. Security firm Socket uncovered the issue. The case demonstrates how a single compromised dependency can poison an entire build.

Related: A signed driver blinds endpoint protection  ·  When attackers outpace the patch

What lurked inside the Injective SDK

What is a supply-chain attack? Instead of targeting a company directly, a supply-chain attack goes after a component used by many. When a public dependency is tampered with, the malicious code flows through the normal installation process to anyone who pulls the package.

In this case, the TypeScript library @injectivelabs/sdk-ts-a tool for applications around the Injective blockchain-was affected. A tampered version included a function masquerading as telemetry. In reality, it harvested credentials. The call to derive a wallet from a mnemonic logged the entire phrase, while the call using a private key captured its material.

The stolen data was base64-encoded and silently sent via a network request to an obfuscated endpoint. The process remained invisible to developers. The package sees around 50,000 downloads per week. The malicious version was also distributed through 17 other Injective packages. Anyone who included one of these was exposed, even if they never directly installed the original library.

How the backdoor slipped into the code

The entry point was the official project itself. The malicious function made its way into the GitHub repository via commits from an account with a long contribution history-exactly the kind of profile that raises no red flags. That’s what makes hijacking an established contributor so effective.

The timeline was telling. Weeks before the release, a test branch with a name hinting at a backdoor check appeared in the repository. Such traces are obvious in hindsight but easily overlooked in the day-to-day of an active open-source project.

Why this affects every build

While this incident wears a crypto label, the pattern is universal. Every modern application pulls in dozens-if not hundreds-of third-party packages, often through multiple layers. A single compromised link is all it takes. Then, the malicious code runs with the same permissions as the build.

Transitive dependencies are particularly risky. A team consciously includes one package but inherits its entire dependency chain-something they never vetted. If credentials, tokens, or keys are stored in a development environment with unchecked dependencies, they’re handing attackers exactly what they’re after.

What Developers and Security Teams Should Do Now

The first question is: Is an affected version running in-house? Without a reliable dependency inventory, the answer is just guesswork. Only then do the technical levers come into play.

Dependency analysis tools cut response time by flagging tampered packages before they’re widely deployed. But the real leverage is organizational: If you don’t know your supply chain, you can’t protect it.

A Supply Chain Stress Test

Injective stated it resolved the incident in under an hour and caused no user harm-a claim from the provider itself. Regardless, the lesson holds: A project’s rapid response doesn’t absolve users of securing their own chain.

For companies subject to NIS2 or DORA, supply chain risk is no longer theoretical. Both frameworks require organizations to manage risks from suppliers and components. A tampered package in your build pipeline is exactly the scenario these regulations target.

Frequently Asked Questions

Each question is locked. Tap to unlock the answer.

What is a supply-chain attack?

A supply-chain attack manipulates a component shared by many targets, such as a public software dependency. The malicious code then spreads through the normal installation process to everyone who includes the package.

Am I affected if I never directly installed the SDK?

Possibly. The compromised version was distributed via 17 other packages. Anyone who included one of those inherited the dependency transitively, without ever directly pulling the actual library.

Is updating to the cleaned version enough?

As a first step, yes-but not as the only one. Keys and mnemonics that passed through an affected version are considered compromised. They need to be rotated, and funds should be moved.

How did the malicious code end up in an official project?

Through commits from an account with a long history of contributions to the official repository. An established contributor raises no suspicion, making the takeover of such an account particularly effective.

What offers the best protection against such attacks?

A well-documented dependency inventory, pinned lockfiles, verified provenance and signatures, and tightly scoped permissions in the build process. Additionally, avoid long-lived secrets in environments with unvetted dependencies.

Editor’s Picks

Editor’s PickOAuth Token Theft: How Attackers Bypass MFAEditor’s PickHow a Ransomware Attack UnfoldsEditor’s PickWhat Really Sets EDR and XDR Apart

More from the MBF Media Network

cloudmagazinFor the first time, you can watch an AI thinkMyBusinessFutureFrom pilot to scale: AI in SMEsDigital ChiefsIT determines whether the spin-off pays off

Image source: AI-generated (July 2026)