Topic starter
02/08/2026 9:48 am
TL;DR: Wallet mnemonics and private keys were captured during ordinary Injective SDK use, according to Aikido. Runtime secret handling in trusted package paths can turn routine calls into exposure events.
Editorial analysis by NHI Mgmt Group, based on content published by Aikido: “Compromised @injectivelabs/sdk-ts exfiltrates wallet keys through fake telemetry”.
Key questions
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: 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.
Glossary terms: Secret-processing dependency, Transitive Dependency, Runtime Secret Capture, Telemetry masquerade
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 2 days ago by NHI Mgmt Group
02/08/2026 12:39 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Compromised Injective SDK exposes wallet keys through fake telemetry