Injective Labs npm backdoor hid stolen crypto keys in legitimate telemetry traffic
On July 8, 2026, version 1.20.21 of @injectivelabs/sdk-ts was published to npm with a hidden credential-stealing payload. What made this attack stand out was not the malicious code itself, but where the stolen data went: not to an attacker-controlled domain, but to a genuine Injective Labs infrastructure endpoint, disguised as normal SDK telemetry. Datadog Security Labs named their analysis "not-so-anonymous telemetry" for this reason.
How the attack worked
The malicious code was committed to the Injective Labs GitHub repository by an account belonging to an established contributor with a real history of legitimate commits. The attacker used the repository's trusted-publisher OIDC pipeline to publish the malicious version, meaning the npm package was signed and published through the project's own CI system, not uploaded by an external actor. Bypassing token-based upload controls required only compromising a contributor account with CI write access.
The payload hooked two wallet key-derivation functions: PrivateKey.fromMnemonic() and PrivateKey.fromHex(). These are the two primary entry points for loading wallet private keys and mnemonic seed phrases. When a developer's application called either function, the malware captured the raw secrets, base64-encoded them, and embedded them in the X-Request-Id HTTP header of a request sent to a genuine Injective Labs public endpoint, designed to look like normal telemetry traffic.
Why this was harder to detect
Most supply chain attacks use attacker-controlled domains for exfiltration. Network security tools catch these: the domain is new, unusual, or on a blocklist. This attack used a legitimate endpoint. The traffic looked exactly like normal SDK telemetry. Without application-layer behavioral analysis, the exfiltration would have been invisible to standard network monitoring. Detection requires analyzing what data is embedded in headers of outbound requests to known-good endpoints, not just whether the destination is suspicious.
Scale and impact
The malicious version was live for 49 minutes. In that window it was downloaded 310 times and pinned across 17 additional @injectivelabs scoped packages, creating 87 downstream transitive exposure points with a combined download count exceeding 112,000. Datadog notes that many of these downloads are likely from automated scanners and mirror services. Injective Labs responded quickly, releasing a clean version (1.20.23) within the same hour. No confirmed theft has been reported.
What to do
Update to @injectivelabs/sdk-ts version 1.20.23 or later immediately. Treat any private key or mnemonic seed phrase that passed through PrivateKey.fromMnemonic() or PrivateKey.fromHex() during the exposure window (July 8, approximately 00:00 to 01:00 UTC) as compromised. Rotate those keys before using the updated SDK version. Audit your transitive npm dependencies: developers who did not directly install sdk-ts may still have been exposed through a scoped package that pinned the malicious version.
The broader lesson
Trusted-publisher pipelines (OIDC-based publish from CI) solve one problem: no long-lived npm tokens. They create another: compromise the contributor account or the repository and you own the pipeline. The attacker here did not need an npm token. Controlling a contributor account with CI write access was sufficient. Defense-in-depth for npm publishing should include signed commits with verified author identity, branch protection requiring code review before CI triggers, and a publish step gating on a secondary approver or time delay. The Injective Labs team resolved this in under an hour. The architecture question is how to prevent the initial commit.
Gigia Tsiklauri is a Security Architect and founder of Infosec.ge. Get in touch if you are assessing your CI/CD supply chain security or npm publish pipeline controls.