Compromised Injective SDK exposes wallet keys through fake telemetry

At a glance

What this is: Aikido reports that a malicious @injectivelabs/sdk-ts release exfiltrated wallet mnemonics and private keys through code disguised as telemetry.

Why it matters: This matters because wallet applications, key management workflows, and adjacent IAM programmes all depend on knowing where secrets are derived, handled, and exposed across build and runtime paths.

By the numbers:

• The malicious version was downloaded 310 times before it was pulled.
• The attacker republished the same 1.20.21 version number across 17 other packages in the @injectivelabs scope.

👉 Read Aikido's analysis of the Injective SDK package compromise and key exfiltration

Context

Supply chain compromise is especially dangerous when malicious code hides inside ordinary package updates and only activates during normal application use. In this case, the primary security problem is not installation-time malware detection but runtime secret capture, where wallet mnemonics and private keys are harvested only after derivation begins.

For identity and access teams, the relevance is clear: secrets are often treated as a deployment concern, but this incident shows that credential exposure can occur inside application logic, not just in vaults or CI pipelines. That makes package trust, runtime inspection, and secret minimisation part of the same governance problem.

Aikido's analysis is typical of modern software supply chain abuse in that the payload is small, disguised, and operationally quiet rather than disruptive.

Key questions

Q: What breaks when a compromised package can read secrets during installation?

A: The main failure is that package installation becomes an identity event. If the environment exposes tokens, keys, or certificates while a dependency executes, the attacker does not need application-level access first. They can steal reusable credentials and move into cloud, CI/CD, or internal systems that trust those secrets.

Q: Why do transitive dependencies increase the risk of secret exposure?

A: Because the package you review is not always the package that executes. A poisoned version hidden in a dependency tree can inherit trust from higher-level libraries and reach production without appearing in the top-level manifest. Teams need lockfile and resolution review, not just direct dependency checks.

Q: How do security teams know whether encrypted telemetry is actually trusted?

A: They should confirm that the channel uses the expected trust chain, that the service reads the intended CA and key material, and that the monitoring logs show successful TLS loading rather than fallback behavior. Encryption alone is not proof of trust. The real signal is successful authenticated connection plus continuous telemetry delivery.

Q: What should teams do after a supply chain package has exposed wallet keys?

A: Assume compromise until every affected key path is identified. Revoke or rotate exposed credentials, move assets if they are at risk, and review all systems that resolved the malicious version, including transitive consumers and build artifacts that may have cached it.

Technical breakdown

How runtime secret theft bypasses package-scanning controls

The malicious payload did not rely on install hooks, so scanners that focus on postinstall scripts or dependency metadata would see a clean package. Instead, the code hooked into the normal execution path used to derive wallet keys, which means the steal only happens when the application is already behaving as intended. That is a classic supply chain weakness: trust is granted at install time, but the harmful action occurs later, inside legitimate business logic. Because the code looked like telemetry, reviewers had to inspect build artifacts and call graphs to see the abuse.

Practical implication: inspect runtime entry points for secret handling, not just package manifests and lifecycle scripts.

Why transitively pinned dependencies expand exposure

The attacker republished 17 related packages with a dependency pin to the poisoned SDK version, so a team could inherit the malicious code without directly installing the compromised package name. This matters because dependency review often stops at the direct manifest, while modern JavaScript supply chains resolve deeply through transitive trees. In practice, the risk is not just whether a package is trusted, but whether any referenced version in the full dependency graph can pull in a poisoned implementation. That makes lockfile review and version pinning governance controls, not just developer convenience.

Practical implication: validate the full dependency graph and lockfile before release, especially for wallet and key-management libraries.

How exfiltration was disguised as normal network traffic

The stolen mnemonic or private key material was batched, base64-encoded, and sent in a request that used gRPC-web headers and a domain shaped to resemble legitimate infrastructure. That approach reduces obvious network anomalies and makes simple destination allow-listing less effective because the endpoint can blend into expected application traffic. The attacker also stored the target domain as character codes, which weakens static detection. This is a good example of why malware in software supply chains increasingly behaves like a stealthy data-exfiltration component rather than a noisy dropper.

Practical implication: monitor for secret-bearing requests and unusual headers, not only for overt malware signatures.

Threat narrative

Attacker objective: The attacker aimed to harvest wallet mnemonics and private keys so they could reconstruct wallets and steal funds.

1. Entry occurred through a malicious npm package release that replaced a trusted dependency version inside the @injectivelabs scope.
2. Credential access happened when the package intercepted mnemonic and private-key derivation inside normal application execution.
3. Impact was secret exfiltration to an attacker-controlled endpoint, with transitive dependency poisoning extending exposure across related packages.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Runtime secret capture is the real failure mode here: the malicious package did not need to break application behaviour, only wait until keys were derived. That means conventional package trust controls can pass while the actual security boundary is already lost. For teams managing NHI and secrets workflows, the lesson is that secret handling inside application code is part of identity governance, not merely software hygiene. Practitioners should treat runtime derivation paths as sensitive control points, not implementation detail.

Transitive trust is now a governance problem, not a dependency-management detail: the poisoned version spread through 17 republished packages, which means a clean top-level manifest is no longer enough evidence of safety. This is the same structural weakness that appears in NHI sprawl, where one compromised credential can propagate through related services. The named concept here is transitive secret exposure: a single poisoned component creates multiple downstream points where secret material can be captured. Security teams should govern dependency trees with the same rigour they apply to privileged access paths.

Telemetry camouflage weakens both static and network-based assurance: the code was framed as usage metrics, then exfiltrated in headers that resembled ordinary gRPC-web traffic. That blend of behavioural normality and secret theft is exactly why supply chain controls must include runtime inspection, egress scrutiny, and provenance checks. In identity terms, the package behaved like an untrusted intermediary handling secrets on behalf of the workload. Practitioners should assume adversaries will hide secret theft inside legitimate instrumentation paths.

Wallet libraries deserve the same control treatment as privileged identity infrastructure: private keys and mnemonics are high-value credentials, and their exposure has direct financial and governance impact. Organisations often separate application security from identity and secrets governance, but this case shows those boundaries collapse at runtime. The practical conclusion is to bring wallet SDKs, secret derivation code, and key custody paths into the same review model used for privileged access and sensitive service accounts.

Rapid maintainer response reduced damage, but it did not erase exposure: the malicious release remained downloadable and the report warns that any mnemonic or private key that passed through the package should be treated as exposed. That is the operational reality of supply chain compromise: containment starts with identifying every affected execution path, not with assuming package deprecation equals safety. Teams should plan for replacement, rotation, and exposure verification as one response sequence.

From our research:

• the average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• From our research: only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to The State of Secrets in AppSec.
• Secret handling now sits at the intersection of application security and identity governance, so practitioners should pair developer controls with NHI-focused lifecycle guidance from Ultimate Guide to NHIs , Key Challenges and Risks.

What this signals

Transitive secret exposure is becoming a practical governance concept for security programmes that rely on third-party packages, because one poisoned dependency can place multiple secret paths under attacker control. Teams should extend review beyond manifests into runtime behaviour, lockfile provenance, and egress monitoring, then connect those checks to the same controls they use for sensitive service accounts and other NHI-adjacent credentials.

The broader signal is that secret governance is now a runtime discipline. When application code can silently exfiltrate key material through seemingly normal instrumentation, the boundary between software supply chain security and identity security disappears. That is why controls from MITRE ATT&CK Enterprise Matrix and secret governance guidance from The State of Secrets in AppSec should be used together, not in isolation.

For practitioners

• Audit transitive dependency trees for wallet and key-management libraries Review lockfiles, nested dependencies, and scope-wide version pins to identify any path that can resolve to the compromised 1.20.21 release or similar poisoned packages. Do not stop at direct dependencies.
• Treat mnemonic and private-key derivation as a monitored control point Instrument runtime paths where secrets are derived or loaded so that unexpected hooks, additional network calls, or secret-bearing telemetry can be detected during normal application use.
• Block secret exfiltration over disguised application traffic Inspect outbound requests carrying unusual headers, encoded payloads, or service domains that resemble internal infrastructure. Secret theft may use legitimate content types and request shapes to avoid obvious alarms.
• Rotate any wallet credentials exposed through affected package versions Assume exposure if mnemonics or private keys passed through the compromised SDK during the affected window. Move funds where needed, then rotate seed phrases and associated keys under a controlled incident process.

Key takeaways

• A malicious package can steal wallet keys during normal execution even when install-time checks look clean.
• Transitive version pins and telemetry-like exfiltration make supply chain compromise harder to spot and easier to spread.
• Teams should treat runtime secret derivation, dependency resolution, and credential rotation as one governance problem.

Key terms

• Transitive Secret Exposure: A condition where a compromised dependency or intermediary package exposes secrets through downstream software paths that were not directly selected by the operator. The risk extends beyond the top-level manifest because the real execution path can emerge through nested dependencies, runtime hooks, and hidden version pins.
• Runtime Secret Capture: The interception of credentials, keys, or recovery material while an application is actively using them, rather than at install or build time. This matters because the secret can be valid, decrypted, and in memory exactly when the attacker reads it, making the compromise hard to detect with static checks alone.
• Wallet Credential: A private key, seed phrase, or mnemonic that authorises control over a crypto wallet and its assets. Unlike a password, it can directly transfer value or permanently expose funds if it is stolen, so lifecycle handling, monitoring, and revocation need to be treated as high-risk identity controls.

What's in the full analysis

Aikido's full blog covers the operational detail this post intentionally leaves for the source:

• The exact malicious code paths in the compiled package artifacts and how they were diffed against the clean build.
• The affected package list, version pinning pattern, and the transitive resolution chain that widened exposure.
• The network indicators of compromise, including the exfiltration endpoint and file hashes used for detection.
• The remediation note on upgrading affected packages to the clean 1.20.23 release.

👉 Aikido's full post covers the attack chain, affected packages, and remediation details

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management. It gives practitioners a practical way to connect identity controls to the broader security programme they operate.