npm supply-chain malware is stealing Polymarket wallet keys

At a glance

What this is: Panther says a malicious npm package targeting Polymarket bots combined runtime execution, SSH persistence, and credential theft in a single supply-chain attack.

Why it matters: It matters because developers often treat bot credentials, SDK files, and Linux access as separate risks, when this pattern shows they can be chained into direct wallet compromise and persistent host access.

By the numbers:

• Polymarket carried $477M in open interest when the malicious package was published.

Context

npm supply-chain attacks matter because a package can execute with the same trust as an internal dependency while also inheriting access to local secrets and developer sessions. In this case, the security gap was not just malicious code in a package, but the overlap between bot credentials, wallet keys, and host-level access on Linux.

For IAM and NHI practitioners, the relevant boundary is not where the package was installed but where its trust extended. An npm import that can read project files, steal API credentials, and write SSH authorized keys crosses from software supply-chain risk into machine identity abuse and persistent access governance.

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. That allows an attacker to fingerprint the host, read local secrets, and create persistence while still returning a valid object to the calling program. In practice, the package boundary is no longer a safe boundary.

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. If a malicious package reaches that context, it can steal both off-chain API access and on-chain signing capability, which turns one host compromise into direct fund risk. Segmentation is weak when the bot and the wallet share the same trust chain.

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. Also check for outbound connections to unfamiliar domains and file access patterns that focus on credential files, SDK source files, or home-directory sweeps. Those signals together indicate the host may have moved from theft to persistent access.

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.

Technical breakdown

Why require() time execution changes the trust model

This package runs as soon as the module is imported, which means the malicious logic fires before any explicit user action inside the application. In Node.js ecosystems, that matters because the import path is often treated as passive dependency loading rather than an execution boundary. A package that behaves normally after returning a Logger object can still run arbitrary code during import, which defeats superficial install-time checks. The result is a hidden execution path that sits inside routine developer workflows and bypasses assumptions that risk only appears during installation or deployment.

Practical implication: Treat dependency import as an execution event and inspect packages for runtime side effects, not just install hooks.

How the SSH backdoor creates persistent machine access

The malware appends an attacker-controlled public key to ~/.ssh/authorized_keys on Linux, creating a durable login path that survives package removal. That is a classic persistence mechanism because the attacker no longer depends on the malicious package remaining present or the victim re-running the application. It also changes the incident from credential theft to host compromise: even if the exposed API keys are rotated, the attacker may retain shell access through SSH. The key detail is that the malware uses standard OpenSSH permission handling, so the change can look operationally valid unless the file is explicitly checked.

Practical implication: Monitor authorized_keys changes from non-shell processes and assume Linux host compromise if a package can write to that file.

Why SDK-specific file targeting is more dangerous than generic .env scanning

Instead of broadly hunting for environment files only, the malware looks for Polymarket SDK source filenames such as createClobClient.ts and clob.ts, then sends the results to a dedicated exfiltration endpoint. That shows the attacker understood the developer workflow and the credential layout around the SDK, including where wallet and trading credentials are typically stored. This is more precise than opportunistic credential theft because it narrows the search to files most likely to contain both API credentials and wallet private keys. It also means generic secret scanning may miss the behavioural signal if defenders only look for obvious .env reads.

Practical implication: Correlate file access patterns with SDK-specific source names and treat targeted reads as higher-risk than bulk secret discovery.

Threat narrative

Attacker objective: The attacker appears to want persistent access to developer hosts and direct control over Polymarket trading credentials and wallet funds.

1. Entry occurred when developers imported [email protected], which executed immediately at require() time without using install hooks.
2. Credential harvesting followed as the package crawled project files and .env content, including Polymarket CLOB credentials and wallet-related secrets.
3. Persistence was established on Linux when the malware wrote an attacker key into ~/.ssh/authorized_keys, creating a standing SSH login.
4. Impact was potential theft of trading authority and wallet control, with direct exposure of bot-managed funds and project data.

Breaches seen in the wild

• Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Solana web3.js npm compromise 2024: A phished maintainer's npm access let attackers publish two @solana/web3.js versions that stole private keys from bots and apps.

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

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.

Persistent SSH access is the governance failure this campaign exploits. The malware does not merely steal credentials, it creates a standing access path that survives the original compromise event. That exposes a control gap around machine identity lifecycle, especially where developer endpoints can still accept long-lived authorized_keys entries without central oversight. The practitioner lesson is to treat unauthorized SSH persistence as an NHI control failure with host-level blast radius.

SDK-specific targeting shows why generic secret controls are not enough. The attacker did not rely on broad .env scraping alone; it built around a known application workflow and file structure. That is the kind of precision that defeats shallow hygiene programs and makes workload context part of identity risk. The practitioner conclusion is that secrets governance has to understand application-specific credential placement, not just file extensions.

Polymarket-style bot environments collapse human, workload, and wallet identity into one compromise surface. A developer workstation holding bot code, CLOB credentials, and a wallet private key is effectively a composite identity system with weak segmentation. In that model, a single malicious package can move from developer execution to trading authority and on-chain asset control. The practitioner conclusion is to govern bot environments as high-risk identity platforms, not as ordinary development laptops.

What this signals

Persistent package-level execution should be treated as identity risk. When a dependency can load code, harvest secrets, and establish SSH access before any user-visible action, the programme has already lost control of its trust boundary. The operational response is to govern developer endpoints and bot runtimes as part of the identity plane, not as separate hygiene domains.

Composite bot environments need tighter separation between code, secrets, and signing authority. The pattern here is not just theft of a file, but collapse of workload access, wallet control, and host persistence into one path. Teams running automated trading or other credentialed bots should assume that a single dependency compromise can become a full identity compromise if those functions are co-located.

For practitioners

• 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.
• Hunt for SDK-specific file access Add detection for unexpected reads of createClobClient.ts, clob.ts, env.ts, and config.ts outside normal build or runtime paths, because targeted filename access indicates deliberate credential harvesting.
• Rotate trading and wallet credentials after host compromise If a Linux bot host ran a malicious package, treat the workstation and any connected wallet or API credentials as exposed and rotate all trading authority before resuming operations.

Key takeaways

• The core risk is not merely a malicious package, but a dependency that can turn routine module loading into secret theft and host persistence.
• This incident links package trust, Linux SSH access, and wallet credential exposure into one compromise path that can outlive package removal.
• The most effective limiting control is to separate signing authority and secret storage from developer workstations, then watch for unauthorized SSH persistence.

Key terms

• Import-time execution: Import-time execution is code that runs when a Python module is loaded rather than when a user deliberately calls a function. That behaviour matters in security reviews because it can trigger secret access, network calls, or persistence before an application has meaningfully started operating.
• SSH Authorized Keys Persistence: A persistence technique where an attacker writes a public key into a user's authorized_keys file to create ongoing shell access. The access survives package removal and often remains valid until the key is manually removed, which makes it a durable host compromise indicator.
• SDK-Specific Credential Targeting: A focused theft pattern where malware looks for files and source names tied to a specific software development kit rather than scanning broadly for all secrets. This is more dangerous than generic credential hunting because it reflects knowledge of how a particular application stores and uses sensitive access material.
• Composite Bot Identity: A situation where code, secrets, signing authority, and execution context are concentrated in one automation environment. When a trading bot or similar workload holds multiple credential types, a single compromise can affect both the machine and the assets the workload controls.

Deepen your knowledge

NHI Foundation Level course covers NHI governance, machine identity security, and secrets management through the industry's only accredited NHI security programme. It helps practitioners connect identity controls to the operational risks that emerge in modern developer and automation environments.