Notifications
Clear all
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.
NHIMG editorial — based on content published by Panther covering the Polymarket npm malware campaign: Polymarket Trader Funds at Risk: DPRK npm Package Steals Wallet Keys and Installs SSH Backdoor
Questions worth separating out
Q: What breaks when npm malware targets both source files and secret files?
A: The break point is trust in the developer workstation.
Q: Why do bot credentials create outsized risk in trading automation?
A: Bot credentials often carry real transactional authority, not just read access.
Q: What do security teams get wrong about detecting malicious packages?
A: They often focus on known-bad signatures and miss behaviour that looks legitimate until the package runs.
Practitioner guidance
- Inventory every bot credential path Map where L2 API keys, L1 wallet private keys, passphrases, and SSH material are stored across developer workstations, repos, and .env files.
- Alert on unauthorized authorized_keys changes Treat any non-shell process writing to ~/.ssh/authorized_keys as a high-priority incident.
- Detect SDK-specific secret hunting Monitor for Node.js reading createClobClient.ts, clob.ts, env.ts, or config.ts outside expected package paths shortly after npm activity.
What's in the full article
Panther's full blog covers the operational detail this post intentionally leaves for the source:
- The full malware analysis of require-time execution, including how the payload avoids install hooks and hides behind a normal logger interface.
- The dedicated exfiltration paths for system data, project secrets, and SDK source files, including the exact file names and endpoints involved.
- The Linux persistence mechanism that writes an SSH key into authorized_keys and survives package removal.
- The indicator list and detection logic that can be adapted into SOC and endpoint rules.
👉 Read Panther's analysis of the Polymarket npm malware campaign →
Polymarket bot malware: what NHI teams need to act on?
Explore further
02/08/2026 12:57 pm
Credential theft is no longer the only failure mode in developer supply chains. This incident shows that a malicious package can convert ordinary import behaviour into both secrets exposure and durable host access. The control gap is not just missing malware detection, but missing governance over where non-human credentials are stored and how developer machines are protected after package execution. For practitioners, that means supply-chain risk and NHI risk now overlap in the same workflow.
A few things that frame the scale:
- Two-thirds of enterprises have endured a successful cyberattack resulting from compromised non-human identities, with a quarter encountering multiple attacks, according to The 2024 ESG Report: Managing Non-Human Identities.
- The average organisation believes more than 1 in 5 of their non-human identities are insufficiently secured, according to The 2024 ESG Report: Managing Non-Human Identities.
A question worth separating out:
Q: Who is accountable when developer tools expose non-human identities?
A: Accountability sits with the team that owns the automation path, the secrets handling, and the endpoint control plane. For regulated or material trading workflows, that also means security, platform engineering, and application owners must agree who can create, store, rotate, and revoke bot credentials before any incident occurs.
👉 Read our full editorial: npm supply-chain malware is stealing Polymarket wallet keys
