Compromised Injective SDK exposes wallet keys through fake telemetry

At a glance

What this is: A malicious Injective SDK release exfiltrated wallet mnemonics and private keys by disguising theft as telemetry inside normal key-derivation code.

Why it matters: Wallet teams and identity security practitioners should treat SDKs that handle secrets as part of the trusted attack surface, because compromised transitive dependencies can expose high-value credentials without breaking application behaviour.

Context

This is a supply chain compromise with a clear secrets-handling dimension. The package behaved like a normal wallet SDK while silently intercepting mnemonic and private-key derivation, which means conventional install-time review would not have revealed the theft path. For identity and NHI governance, the important point is that runtime secret handling inside dependencies can become an unseen control failure even when the application itself appears intact.

The article also shows why dependency scope matters beyond direct imports. Repinning the same poisoned version across 17 related packages turned a single malicious release into a transitive exposure problem for wallet workflows, token custody, and other secret-bearing integrations. That is a typical modern software risk pattern, but here the compromised asset was wallet material rather than generic application data.

Key questions

Q: What breaks when wallet SDKs silently call secret-derivation code at runtime?

A: The main failure is that every wallet creation or load becomes a secret exposure event. If an SDK runs hidden telemetry inside key derivation paths, it can capture mnemonic phrases or private keys before the application can inspect them. Security teams should assume any affected install touched by that code has exposed wallet secrets and rotate or invalidate them immediately.

Q: Why do malicious dependencies create more risk than a simple package mismatch?

A: Because the danger is often in the execution path, not just the declared dependency tree. A package can arrive through a trusted channel, run install-time code, and access local secrets before scanners or approvals see anything unusual. That makes runtime behaviour the meaningful control point.

Q: What are the signs that secret theft is hiding inside legitimate telemetry?

A: Look for code that collects values from derivation functions, encodes destinations at runtime, sends data in headers or service-like requests, and suppresses failures. Those patterns indicate exfiltration disguised as instrumentation rather than ordinary observability.

Q: How should teams respond when exposed wallet keys are discovered in a dependency incident?

A: Treat the secrets as compromised, move or protect the assets they control, revoke any access paths tied to them, and replace the affected keys or seed phrases. The response priority is containment of downstream use, not just removal of the package.

Technical breakdown

How the malicious SDK captured wallet secrets at runtime

The compromised package hooked the standard derivation paths used to turn a mnemonic phrase or raw private key into a usable wallet object. Those hooks executed before the real derivation logic, so every legitimate call exposed the secret first. This is different from install-time malware because the package can look harmless in dependency scans, unit tests, or package metadata until the application actually uses the wallet functions. In practice, the attacker did not need to break the SDK’s expected behaviour, only sit inside it at the exact moment secrets were already present in memory.

Practical implication: Treat any dependency that processes secrets as a runtime control point, not just a build-time risk.

Why the exfiltration blended into ordinary network traffic

The payload was designed to resemble normal instrumentation. It rebuilt the destination host from character codes, sent the stolen material in a gRPC-web shaped request, and placed the data in a request header rather than the body. That makes the traffic look like legitimate telemetry or service communication unless defenders inspect the endpoint, header values, and timing patterns together. The attacker also used silent failure handling, so blocked requests would not alert the victim application. This is a classic example of concealment through protocol mimicry and header abuse, adapted for wallet secret theft.

Practical implication: Inspect runtime destinations and unusual header-based exfiltration, not just payload bodies or install scripts.

How transitive package pinning widened the blast radius

Only one SDK package contained the stealer code, but 17 related packages were republished at the same poisoned version and pinned to that dependency. That means a project could ingest the malicious code without naming the compromised SDK directly. For practitioners, the risk is not limited to top-level package names. A dependency graph can import secret-handling code transitively, and the security boundary is therefore the resolved tree, not the manifest line a developer remembers adding. This is why package provenance and lockfile review matter in wallet ecosystems.

Practical implication: Review resolved dependency trees for transitive secret-handling libraries, not just direct package names.

Threat narrative

Attacker objective: The attacker’s objective was to steal wallet-derived secrets so they could reconstruct and control victim wallets.

1. Initial access came through a malicious npm release of a trusted wallet SDK that was published under an existing package name.
2. Credential capture occurred when the application legitimately derived a mnemonic-based or hex-based private key, allowing the payload to copy the secret before the real wallet object was built.
3. Exfiltration used disguised telemetry sent to an attacker-controlled endpoint that blended into normal gRPC-web traffic.
4. Impact was exposure of wallet mnemonics and private keys, creating a direct path to asset theft and account compromise.

Breaches seen in the wild

• Secrets in Docker Hub images (RWTH Aachen study): A 2023 RWTH Aachen study found secrets in 8.5% of container images, and 275,269 internet hosts still using the leaked private keys.
• Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Runtime secret handling is the real trust boundary in modern supply chains: package approval alone does not govern what a dependency does after it is loaded. This case shows that wallet SDKs can exfiltrate secrets only when the application is already operating normally, which means build-time review misses the decisive control point. Practitioners should treat secret-bearing runtime paths as a separate governance domain.

Transitive dependency poisoning creates a hidden NHI exposure model: the compromised SDK was only one package, but the poisoned version propagated through 17 related packages that wallet projects would reasonably trust. That pattern matters because a dependency tree can carry secret-handling code far beyond the package a team thinks it installed. In NHI terms, the governance object is not the library name but the resolved path that can touch keys, tokens, or seed phrases.

Telemetry is a dangerous camouflage pattern when the asset is a secret: attackers do not need novel malware when ordinary instrumentation can be repurposed to move wallet material off-host. The named concept here is telemetry masquerade exfiltration, where harmless-looking metrics channels become the disguise for credential theft. Security teams should assume that any code path claiming to observe secret derivation needs explicit scrutiny before it is trusted.

Wallet custody programs need supply chain controls, not just wallet controls: the compromise sits at the intersection of software provenance, secret management, and operational recovery. Once a package can observe seed phrases or private keys at runtime, downstream wallet governance is already weakened. The practical conclusion is that provenance assurance and secret-boundary control have to be designed together, not treated as separate programme tracks.

This incident validates the need for secret-aware dependency governance: software inventories that do not distinguish between ordinary libraries and secret-processing libraries leave teams blind to the highest-consequence packages. For identity and NHI practitioners, the lesson is that any library with access to derivation, authentication, or token material deserves stricter approval, monitoring, and offboarding rules than general application dependencies.

What this signals

Telemetry masquerade exfiltration: when malicious code hides secret theft inside instrumentation, reviewers lose the obvious behavioural cues they rely on. For wallet and identity teams, that means any dependency that touches derivation, authentication, or token handling must be evaluated as a secret boundary, not a convenience library.

Dependency graph review now has to include the runtime path that touches secrets, because republished transitive packages can carry the highest-risk behaviour even when the top-level package looks clean. In practical terms, package provenance, lockfile integrity, and secret-aware code review belong in the same control conversation.

For practitioners

• Review transitive dependencies that handle wallet secrets Trace resolved package trees for SDKs that derive mnemonics, private keys, tokens, or certificates, not just direct imports, and flag any package that can observe secret material at runtime.
• Quarantine and rotate exposed wallet material Assume any mnemonic or private key processed by a compromised package is exposed, then move funds, revoke dependent access, and replace the affected credentials with fresh ones.
• Separate secret processing from ordinary telemetry Require explicit approval for any library that emits metrics from secret-derivation code paths, and block outbound destinations that are not part of a documented trust list.
• Scan for package provenance drift across the dependency graph Compare lockfiles, resolved versions, and release metadata across the full tree so a republished package or pinned transitive version cannot bypass review.
• Tighten runtime detection on header-based exfiltration Alert on unusual request headers, encoded endpoints, and service-like traffic patterns from libraries that should never need to transmit secret-bearing payloads.

Key takeaways

• This compromise exposed wallet mnemonics and private keys through ordinary SDK calls, which means the attack succeeded inside a trusted runtime path rather than at install time.
• The poisoned release propagated through 17 related packages, showing how transitive dependency reuse can widen the blast radius of a single malicious version.
• Teams need controls that govern secret-processing libraries, runtime destinations, and transitive package provenance together, because any one of those gaps can leave wallet material exposed.

Key terms

• Secret-processing dependency: A library or package that handles sensitive material such as mnemonics, private keys, tokens, or certificates during normal application execution. These dependencies deserve stricter review because compromise can expose live secrets even when the package installs cleanly and appears to function as expected.
• Transitive Dependency: A transitive dependency is a package that your software uses indirectly through another library rather than calling it directly. These dependencies often hide in Java estates, which makes visibility and runtime validation necessary to understand what code is actually present and active.
• 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.
• Telemetry masquerade: A concealment technique where malicious code frames data theft as logging, metrics, or instrumentation. The disguise is effective because defenders often treat telemetry as low-risk, even though the same channels can be repurposed to carry secrets off-host.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management for practitioners building stronger control boundaries. It helps identity and security teams apply consistent governance to credentials, service accounts, and other non-human identity risks.