npm supply-chain malware is stealing Polymarket wallet keys

At a glance

What this is: This is Panther’s analysis of a malicious npm package that targets Polymarket bot developers, steals trading and wallet credentials, and adds SSH persistence on Linux hosts.

Why it matters: It matters because developer workflows now expose both human and non-human identities to supply-chain malware, turning a package import into credential theft, host persistence, and downstream fund risk.

By the numbers:

• Polymarket carries $477M in open interest.

👉 Read Panther's analysis of the Polymarket npm malware campaign

Context

Supply-chain malware in developer ecosystems often succeeds because it targets the way credentials are actually stored and used, not just the application itself. In this case, the primary risk is NHI governance: API keys, wallet keys, and SSH access are all exposed through ordinary build and run-time behaviour.

The article shows a common but dangerous boundary failure. A package import is treated as routine code execution, yet the payload can reach both human-operated development hosts and non-human trading identities. For teams running automated trading, bots, or other credentialed workflows, that combination changes the threat model materially.

Key questions

Q: What breaks when npm malware targets both source files and secret files?

A: The break point is trust in the developer workstation. Once a malicious package can read both application files and .env secrets, it can reconstruct how the bot authenticates and then reuse those credentials outside the intended workflow. That turns a code dependency issue into an identity compromise with potential fund access and host persistence.

Q: Why do bot credentials create outsized risk in trading automation?

A: Bot credentials often carry real transactional authority, not just read access. In this case, API keys can place and cancel trades, while wallet keys can sign on-chain actions and move funds. When those credentials are stored together, one theft can expose both market operations and asset control.

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. A dependency can be harmless in static review but malicious at runtime, especially when it reads credential files, spawns subprocesses, or calls unexpected external endpoints. Behavioural telemetry is the control that closes that gap.

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.

Technical breakdown

Require-time execution and why it matters for npm security

The package executes when it is imported with require(), which means the malicious logic runs before any visible install hook or traditional setup signal. That pattern bypasses many controls that focus on preinstall and postinstall events. Obfuscation further delays inspection, because analysts must decompile the JavaScript before the true behaviour becomes visible. In practice, this means package trust cannot rely on installation telemetry alone; runtime import behaviour has to be part of detection and review.

Practical implication: monitor require-time behaviour, not just install hooks, when reviewing npm dependencies.

How the malware turns credential files into NHI exposure

The payload reads .env files, project source files, and SDK-specific filenames to locate Polymarket CLOB credentials. That is an NHI problem as much as a malware problem, because API keys and wallet private keys are machine credentials that can be reused outside the intended application path. The attacker does not need interactive access once those secrets are copied. This is a direct example of secrets sprawl meeting application-specific targeting, which is why file-based trust assumptions fail in developer environments.

Practical implication: separate bot credentials from project files and treat source-tree secret discovery as a reportable control failure.

SSH backdoor persistence as an escalation path

On Linux, the malware appends an attacker key to authorized_keys, creating persistent SSH access that survives package removal. That moves the incident from credential theft to host compromise, because the attacker no longer depends on stolen secrets to re-enter the system. The persistence mechanism is simple but effective: it abuses a standard authentication boundary rather than exploiting kernel-level code. This makes identity controls and endpoint monitoring equally relevant, because the first compromise creates a second access path.

Practical implication: treat any unauthorized authorized_keys change as a live persistence event requiring host isolation.

Threat narrative

Attacker objective: The attacker aims to steal trading and wallet credentials, persist on developer hosts, and gain the ability to move funds or operate compromised Polymarket accounts.

1. Entry occurs through a malicious npm package that runs at require() time when developers import it into a Polymarket bot environment.
2. Credential access follows as the payload reads .env files, SDK source files, and wallet-related secrets from the project tree.
3. Escalation occurs when the malware writes an attacker SSH key into authorized_keys on Linux hosts, creating persistent access beyond the stolen credentials.
4. Impact is the theft of Polymarket trading and wallet keys, plus potential host persistence that can enable fund drain and continued compromise.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• IOS app secrets leakage report — iOS apps leaking hardcoded secrets and credentials endangering user privacy.

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

NHI Mgmt Group analysis

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.

SDK-specific targeting is a stronger signal than generic .env scraping. The package did not merely hunt for common secret names. It sought Polymarket client files by name, which shows the attacker understood the application path and credential structure. That level of targeting makes broad DLP-style scanning less reliable unless it is paired with workload-specific secret inventory and file-access monitoring. Practitioners should assume specialised malicious packages will mirror legitimate developer patterns.

Standing SSH access reveals a governance assumption that developers can simply remove the package and recover. That assumption failed here because the attacker persisted through authorized_keys, not through the package itself. This is the specific failure mode: untracked local account access created by malware on a developer endpoint. Teams need endpoint telemetry that treats identity changes on workstations as security events, not just authentication maintenance.

Prediction-market and crypto-adjacent workflows need NHI controls, not only code review. The article makes clear that bot operators often store L2 API credentials and L1 wallet keys together, which collapses application access and fund control into one compromise path. That is a classic non-human identity boundary problem. Without separate storage, rotation, and host-hardening practices, the bot becomes an easy bridge from repository compromise to financial loss.

Polymarket bot security is now a question of blast-radius control. If one developer workstation can expose both credentials and a persistent SSH path, the programme has already lost containment. The right question is not whether the package looked legitimate, but how much authority any single bot credential can carry across trading, signing, and host access. Practitioners should reduce the amount of trust concentrated in each automation path.

From our research:

• 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.
• From our research: 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.
• Forward pivot: For teams formalising NHI controls, review Ultimate Guide to NHIs , Key Challenges and Risks alongside attack-driven guidance on credential rotation and exposure reduction.

What this signals

Secret sprawl and endpoint persistence now belong in the same governance conversation. When developer tools can expose both wallet keys and workstation SSH access, identity risk is no longer confined to vaults or IAM dashboards. Teams need to treat file access, package execution, and local account changes as one control plane, and tie that work to NIST Cybersecurity Framework 2.0 and NIST SP 800-53 Rev 5 Security and Privacy Controls where identity and audit controls intersect.

Standards-based NHI governance is becoming a practical requirement, not a specialist concern. The pattern here aligns with the access-control and authenticator-management problems described in the Top 10 NHI Issues, especially where automation credentials are embedded in development workflows. Practitioners should expect more incidents where application secrets, human endpoints, and non-human identities fail together.

Credential containment is the next maturity test for automation-heavy programmes. The key question is whether one compromised package, host, or repo can still expose trading authority, wallet signing power, and administrative access in a single step. If the answer is yes, the programme has not separated identity from operational convenience well enough to withstand supply-chain malware.

For practitioners

• 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. Eliminate shared storage locations that let one package import expose both trading authority and host access.
• Alert on unauthorized authorized_keys changes Treat any non-shell process writing to ~/.ssh/authorized_keys as a high-priority incident. On Linux development hosts, isolate the machine immediately, remove attacker keys, and verify whether other persistence or credential theft occurred.
• 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. That pattern indicates targeted credential harvesting rather than generic file access.
• Separate trading authority from wallet control Do not store the wallet private key and API trading credentials in the same project-root .env file. Use distinct secret handling and revoke both credential classes if either is exposed, because one compromise should not unlock both market access and fund movement.

Key takeaways

• Malicious npm packages can now combine secrets theft with persistent SSH access, turning a routine dependency import into a full NHI compromise path.
• The strongest evidence in this case is the coupling of SDK-specific credential targeting with Linux authorized_keys persistence, which shows deliberate preparation rather than opportunistic scraping.
• Teams need to separate trading authority, wallet signing, and endpoint access so that one compromised developer workflow cannot expose all three at once.

Key terms

• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
• Credential Persistence: Credential persistence is the ability of an attacker to keep access after the original secret is revoked or the initial malware is removed. In identity terms, it usually means a second credential, key, or token has been added to the account lifecycle and now survives the first response action.
• Secrets Sprawl: The uncontrolled proliferation of sensitive credentials — API keys, tokens, passwords, certificates — across codebases, cloud environments, CI/CD pipelines, and configuration files. In 2024, over 50 million leaked secrets were found on the dark web.

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.

👉 Panther's full post covers the attack chain, persistence method, and detection indicators in detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners build the control discipline needed to govern automation, credentials, and access lifecycles across the wider security programme.