Topic starter
02/08/2026 11:47 am
TL;DR: A malicious npm package targeting Polymarket trading bots runs at require() time, installs Linux SSH persistence, and exfiltrates wallet keys, API credentials, and project files, putting accounts with $477 million in open interest at risk, according to Panther. The pattern shows how developer tooling, secrets exposure, and persistent host access can converge into a single NHI compromise path.
Editorial analysis by NHI Mgmt Group, based on content published by Panther: “Polymarket Trader Funds at Risk: DPRK npm Package Steals Wallet Keys and Installs SSH Backdoor”.
Key questions
Q: What breaks when a malicious npm package runs at require() time?
A: The normal assumption that risk is limited to installation breaks down, because imported code can execute before the application does anything useful.
Q: Why do trading bots with stored wallet keys create higher compromise risk?
A: Because the bot environment often concentrates trading authority, API credentials, and wallet control in the same execution context.
Q: What are the warning signs that a developer workstation has been used for persistence?
A: Look for unexpected changes to ~/.ssh/authorized_keys, especially when the parent process is node or another non-shell application.
Practitioner guidance
- Inventory npm packages that execute at import time Review Node.js dependencies for side effects that occur during require() or module load, especially in trading, automation, and bot environments where imported code can reach local secrets.
- Block unauthorized writes to authorized_keys Alert on any non-shell process, especially node, creating or modifying ~/.ssh/authorized_keys on Linux endpoints and investigate the source package immediately.
- Separate bot credentials from source trees Move API keys, wallet private keys, and passphrases out of project-root .env files and into managed secret storage with per-environment scoping and short-lived access where possible.
Bottom line: The core risk is not merely a malicious package, but a dependency that can turn routine module loading into secret theft and host persistence.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 12:57 pm
Supply-chain malware is now a machine identity problem, not only a package hygiene problem. When a dependency can read project files, harvest secrets, and write SSH access, the trust boundary has already moved from code integrity into identity governance. That means teams must manage developer tooling as a pathway to privileged access, not only as a software procurement risk. The practitioner conclusion is simple: package trust and host trust can no longer be separated.
A question worth separating out:
Q: How should teams respond after a package has touched bot credentials and SSH access?
A: Assume both credential exposure and host compromise until proven otherwise. Remove the malicious package, inspect authorized_keys, rotate API keys and wallet secrets, and review other systems that reused the same credentials or developer workflow. If trading authority or wallet signing keys were present, treat downstream accounts as potentially exposed as well.
👉 Read our full editorial: npm supply-chain malware is stealing Polymarket wallet keys