The OIDC Double-Edge: Inside the Injective SDK Backdoor

The recent compromise of the Injective Labs TypeScript SDK is a stark reminder that software supply chain security is an arms race where the defense is currently losing ground. On June 8, 2026, threat actors managed to publish a backdoored version of @injectivelabs/sdk-ts to the npm registry. The incident was short-lived, lasting only about 17 minutes before being detected and reverted, but the mechanics of the attack reveal a sophisticated blueprint that bypasses standard static analysis and exploits modern CI/CD trust assumptions.

By moving away from noisy post-install scripts and abusing OpenID Connect (OIDC) trusted publishing pipelines, the attackers turned the project's own secure infrastructure against itself. For developers building on decentralized finance (DeFi) and Web3 platforms, this incident exposes a critical vulnerability: our security tools are looking for yesterday's threats while attackers are already exploiting tomorrow's trust models.

The Anatomy of a Stealthy Backdoor

Historically, npm malware has relied on lifecycle scripts (such as preinstall or postinstall in package.json) to execute malicious payloads. Because security scanners and registry gatekeepers heavily monitor these scripts, modern attackers have adapted. The backdoored Injective SDK version, 1.20.21, contained no install-time triggers. It remained completely dormant until the library was actually used in production.

The attackers targeted the compiled distribution files, specifically /dist/esm/accounts-jQ1GSgaW.js and /dist/cjs/accounts-Cy0p4lLW.cjs. They hooked the legitimate fromMnemonic and fromHex functions inside the PrivateKey class, injecting a call to a malicious trackKeyDerivation function:

static fromMnemonic(words, path = require_constants.DEFAULT_DERIVATION_PATH) {
  trackKeyDerivation("fm", words);
  return new PrivateKey(new ethers.Wallet(ethers.HDNodeWallet.fromPhrase(words, void 0, path).privateKey));
}

To keep the modification from raising immediate red flags during manual code reviews, the attackers disguised the function as an anonymous telemetry feature designed to "track timing patterns" and "identify performance bottlenecks."

Once triggered, the malware captured the mnemonic seed phrase or private key, encoded the data in base64, and queued the payloads. To minimize network noise and avoid triggering anomaly detection systems, the exfiltration mechanism batched multiple captured keys over a two-second window. It then sent them via an HTTPS POST request to testnet.archival.chain.grpc-web.injective[.]network—a public infrastructure endpoint belonging to Injective Labs itself. By routing the stolen credentials to a legitimate project subdomain, the attackers ensured the traffic would blend in with normal application behavior and bypass basic egress firewalls.

The OIDC Trust Paradox

The compromise did not occur because of a leaked npm publishing token. Instead, the attackers compromised the GitHub account of a trusted, established contributor named thomasRalee.

According to security analysis, the suspicious activity began on June 8, 2026, when the compromised account pushed commits to a branch named test-backdoor-check to verify repository permissions. Once access was confirmed, the attacker merged the malicious code and triggered the repository's trusted-publisher pipeline.

OIDC is widely promoted as a security best practice because it eliminates the need for long-lived, hardcoded registry secrets. Under OIDC, the package registry trusts the identity provider (GitHub) to verify that a commit came from an authorized source. However, this creates a single point of failure: if a contributor's GitHub session or credential is hijacked, the OIDC pipeline happily signs and publishes the malware to npm with full cryptographic legitimacy.

To maximize the blast radius, the threat actor also published version 1.20.21 across 17 other scoped packages under the @injectivelabs namespace, including @injectivelabs/wallet-core, @injectivelabs/utils, and @injectivelabs/networks. By pinning these packages to the compromised SDK version, the attackers ensured that any developer pulling down a related utility package would transitively pull down the backdoor, even if they did not import the core SDK directly. With the SDK receiving roughly 50,000 weekly downloads and supporting 87 direct dependents, the potential downstream impact was massive.

The Developer Angle: Hardening Your Supply Chain

If your application interacted with the @injectivelabs/sdk-ts package or any of its scoped siblings at version 1.20.21, you must assume any private keys or mnemonic phrases processed during that window are compromised. Upgrading to the clean version, 1.20.23, will resolve the backdoor, but it will not claw back already exfiltrated secrets. Affected keys must be rotated immediately.

Beyond immediate remediation, this incident highlights several architectural gaps in how we manage dependencies and CI/CD pipelines.

1. Enforce Multi-Party Review for Release Branches

OIDC makes publishing easy, but it must be paired with strict branch protection rules. No single developer account—no matter how trusted—should be able to push code directly to a release branch or merge a pull request without independent approval. Require multi-party review and mandatory commit signing for all code destined for production branches.

2. Implement Runtime Egress Filtering

If your application handles highly sensitive cryptographic material like private keys, it should run in a highly restricted network environment. Even if an attacker injects a runtime hook, they cannot steal your keys if they cannot exfiltrate them. Implement strict egress filtering at the container or network level. There is rarely a legitimate reason for a production backend processing wallet keys to make arbitrary outbound HTTPS requests to external testnets or third-party endpoints.

3. Move Beyond Static AST Scanners

Traditional static application security testing (SAST) tools that look for known vulnerabilities or suspicious package.json scripts would have missed this attack entirely. To catch runtime hooks and obfuscated telemetry, developers should look toward dynamic analysis, runtime application self-protection (RASP), or monitoring network telemetry during integration testing to flag unexpected outbound connections.