TL;DR: A malicious npm package impersonating Polymarket combined cloud credential harvesting, crypto-wallet theft, and RAT-style remote command execution, while also exposing the attacker’s own GitLab SSH keys in cleartext, according to OXSecurity. The pattern shows how package trust, browser extension access, and cloud token collection can converge into a single compromise path, making software supply chain governance and NHI control gaps visible at the same time.
At a glance
What this is: OXSecurity found a malicious npm package, polymarket-kit, that combined credential harvesting, wallet theft, and remote command execution while exposing the attacker’s own GitLab SSH keys.
Why it matters: This matters because package trust failures now reach both cloud access and financial theft, so IAM, NHI, and supply chain controls have to be assessed together.
Context
A malicious package in a software supply chain can behave like any other trusted dependency until its code starts collecting secrets, tokens, and session data. In this case, the risk is not just malware execution but the abuse of developer trust, browser access, and cloud credentials that were reachable through the package’s installation path.
The identity angle is direct: stolen API keys, SSH keys, cloud tokens, and wallet extensions are all credential-bearing assets that can be used to impersonate users or workloads. For teams that manage NHIs and secrets, this is a reminder that dependency trust is also identity trust, and that offboarding and rotation controls must extend into build and endpoint workflows.
Key questions
Q: What breaks when a malicious npm package can read developer secrets during install?
A: The main failure is that package execution inherits identity context it should never need. Once a malicious install can read environment variables, local files, and CI secrets, it can steal credentials that survive beyond the original infection. That turns a code dependency problem into an access-control incident, because the attacker gains reusable authentication material, not just a one-time foothold.
Q: Why do package-based attacks create so much risk for cloud and NHI credentials?
A: Because cloud tokens, API keys, and SSH keys often sit in places that are easy for installed code to reach, including environment files, browser storage, and automation hosts. Once stolen, those credentials behave like machine identities and can be replayed outside the original trust context, which is why local secret exposure quickly becomes remote access risk.
Q: What are the signs that an npm dependency may be hiding malicious code?
A: Warning signs include an unexpected test or helper file that executes network calls, deeply nested imports that lead to unfamiliar modules, obfuscated JavaScript, suspicious file extensions for executable code, and code that collects host data before contacting remote endpoints. Any package that reads environment details, system identity, or browser or wallet data during routine execution deserves immediate review.
Q: How should teams govern software supply chain risk when secrets live on endpoints?
A: They should treat dependency trust, endpoint secrets, and interactive remote control as one control plane. That means restricting where secrets are stored, limiting which runners can access them, and assuming that any package with install-time execution can become a collection layer if local protections are weak.
Technical breakdown
How a malicious npm package becomes an initial access path
Malicious packages exploit the normal trust model of JavaScript dependency installation. Once a package is pulled into a build, developer machine, or automation runner, its install-time logic can execute with the same local privileges as the user or pipeline. In this case, the package impersonated a crypto brand and used that trust to reach victims who were already predisposed to install it. That matters because supply chain compromise does not require direct exploitation of the target system first; it only needs execution in a trusted dependency context where secrets, browser data, or cloud configs are accessible.
Practical implication: Treat package provenance and installation permissions as part of access control, not just software hygiene.
Why browser extensions and cloud tokens are high-value credential targets
Browser wallet extensions and cloud SDK credentials are attractive because they often sit close to active sessions, stored keys, or decrypted local state. Attackers that can enumerate extensions, read extension databases, or locate configuration files can extract both consumer and enterprise identities without needing full system compromise. When a package harvests Google, AWS, or Azure material, it is not just stealing data, it is collecting machine-access credentials that can be replayed elsewhere. This is a classic NHI problem because the exposed material often represents service or application identity rather than a person’s login.
Practical implication: Inventory where cloud tokens and other NHI secrets exist on endpoints, then reduce their exposure to local readable storage.
WebSocket RAT control turns theft into an interactive compromise
A WebSocket-based RAT gives the attacker a persistent command channel over a standard web protocol, which makes the malware more than a one-shot collector. Once the victim machine is linked to the remote server, the operator can run commands, stage additional exfiltration, and adapt in real time to whatever secrets are discovered. That persistence is important because it collapses the line between theft and remote administration. The exposed GitLab SSH keys in the package also show poor operational discipline on the attacker side, but for defenders the larger lesson is that the same path used for collection can become a live control channel.
Practical implication: Monitor for unusual WebSocket usage from development endpoints and automation hosts where remote command execution is not expected.
Threat narrative
Attacker objective: The attacker sought to steal wallet assets and cloud access while keeping a persistent remote control path over compromised systems.
- Entry occurred when users or environments installed polymarket-kit, a malicious npm package masquerading as a Polymarket-related dependency.
- Credential access followed as the payload enumerated browser extensions, decrypted local databases, and searched for cloud configurations, tokens, wallets, and SSH material.
- Impact came from exfiltration of crypto-wallet data and cloud credentials, with the malware also providing a RAT channel for remote command execution through WebSocket.
Breaches seen in the wild
- tj-actions/changed-files compromise 2025: A stolen bot token let attackers poison tj-actions/changed-files so pipelines printed their CI/CD secrets to public logs (CVE-2025-30066).
- CircleCI breach 2023: Malware stole a CircleCI engineer's SSO session; attackers exfiltrated customers' CI/CD secrets and keys, forcing a platform-wide rotation.
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
Software supply chain compromise is now an identity problem as much as a code integrity problem. polymarket-kit did not need to break cryptography or exploit a cloud provider to create damage. It relied on trusted installation paths to reach credential stores, extension data, and cloud tokens. The practitioner conclusion is that dependency governance and credential governance now overlap operationally, especially where build runners and developer endpoints can see NHI secrets.
NHI exposure on endpoints is the real prize in many npm malware campaigns. The article’s cloud token harvesting shows how easily machine credentials can be lifted once local access exists. Service tokens, SSH keys, and API keys are not abstract artefacts in this pattern, they are the operational identity layer that enables lateral movement and persistence. Teams need to assume endpoint exposure can become NHI compromise in a single step.
The exposed GitLab SSH keys in the package are a useful reminder that attacker tradecraft is often careless even when the malware is effective. That sloppiness does not reduce the risk to defenders. It does, however, reinforce a named concept we should track: dependency trust inversion, where the install source is treated as benign while the package itself becomes the attacker’s delivery and control plane. The practical conclusion is that trust boundaries must move left into package provenance and secret exposure review.
WebSocket RAT capability broadens the incident from credential theft to interactive compromise. Once a package can issue commands and stage uploads over a persistent channel, incident scope is no longer limited to which secrets were copied. The security question becomes which host actions the attacker could have triggered after initial theft. Practitioners should treat the malware as both a collection tool and a remote administration layer, which changes containment priorities.
Supply chain defence must now account for the convergence of software trust, browser trust, and identity trust. In this case, a package targeted wallet extensions, cloud credentials, and SSH artefacts in one workflow. That convergence argues for governance that spans software inventory, secret lifecycle control, and high-risk endpoint telemetry. The practitioner conclusion is straightforward: a narrow supply chain lens will miss the identity blast radius.
From our research library:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
- Breaches involving third parties rose to 48% of all breaches, a 60% increase on the previous year, according to Verizon's 2026 Data Breach Investigations Report.
- Read next: API Key Management Guide
What this signals
Dependency trust inversion is the most useful concept in this incident: the thing installed for convenience becomes the channel for credential theft and remote control. Once that happens, package provenance, endpoint storage, and secret lifecycle controls stop being separate concerns and become one governance problem.
Teams should expect more malware to combine browser-extension access with cloud-token harvesting because that pairing gives attackers both user-context secrets and machine-context secrets. The operational answer is to reduce where credentials can be decrypted locally and to make high-risk installs observable through endpoint telemetry.
The broader implication for practitioners is that supply chain controls only work when they are paired with secret minimisation. If NHIs and browser-managed credentials remain available on the same host that installs untrusted packages, the attack surface stays open even when software provenance checks are in place.
For practitioners
- Remove the affected package from all environments Uninstall polymarket-kit wherever it is present and search for the package name across developer laptops, CI runners, and build artefacts to confirm there are no residual copies.
- Rotate cloud and SSH credentials touched by the host Revoke any AWS, Azure, Google Cloud, GitLab, or SSH credentials that may have been accessible on the affected machine, including tokens stored in local config files or browser-managed secrets.
- Audit browser extensions for wallet and identity exposure Check browser extension inventories on developer and crypto-user endpoints, then review which extensions stored local state that the malware could decrypt or exfiltrate.
- Block suspicious WebSocket command-and-control patterns Inspect endpoint and proxy logs for unusual outbound WebSocket sessions from developer workstations and automation hosts, especially where those sessions coincide with secret-access activity.
- Review build and endpoint trust boundaries Separate package installation, credential access, and interactive admin paths so that a single dependency cannot see both source code and live secrets on the same host.
Key takeaways
- This incident shows that an npm package can become a multi-purpose compromise path when it can reach cloud tokens, wallet data, and remote command execution in the same workflow.
- The key evidence is the combination of credential harvesting, WebSocket-based control, and exposed SSH material, which makes the compromise both broader and harder to contain.
- Reducing local secret exposure and tightening dependency trust boundaries would have limited the attacker’s reach far more effectively than treating the package as a simple malware sample.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The package exposed and harvested secrets from local stores and configs. |
| NHI-03 — Vulnerable Third-Party NHI | A third-party package acted as the trusted entry point for credential theft. | |
| NHI-07 — Long-Lived Secrets | Cloud tokens and SSH keys on endpoints remain usable long after package installation. | |
| Recommendation — Scan package installs and endpoint storage for leaked NHI secrets and revoke anything exposed. Review third-party package trust paths that can reach machine credentials or browser-stored secrets. Replace long-lived endpoint secrets with tighter issuance and faster revocation cycles. | ||
| MITRE ATT&CK | TA0006;TA0011 — Credential Access; Command and Control | The campaign combines secret collection with a persistent WebSocket control channel. |
| Recommendation — Map the package behaviour to credential access and C2 techniques in detection and hunting workflows. | ||
| CIS Controls v8 | CIS-5 — Account Management | Compromised package access enables misuse of cloud and GitLab accounts. |
| Recommendation — Harden account and credential lifecycle controls so installed code cannot reach reusable secrets. | ||
Key terms
- Dependency Trust Inversion: A failure mode where the software package or dependency that is supposed to be trusted becomes the delivery path for theft or control. In practice, install-time execution, local secrets, and developer convenience combine to give attackers the same access as the legitimate user or pipeline.
- WebSocket Rat: Malware that uses WebSocket connections as a persistent remote command channel. The protocol choice can make control traffic look like ordinary application communication while still allowing the attacker to issue commands, stage exfiltration, and maintain live access.
- Endpoint secret exposure: Endpoint secret exposure occurs when credentials are stored or cached on developer laptops, runners, or other local systems outside central controls. It matters because local environments often bypass normal vault, rotation, and revocation processes even though they can still authenticate to production systems.
- Third-Party Nhi Risk: The risk that a trusted external package, service, or integration can access, misuse, or expose non-human identity credentials. This is a governance problem because the identity may belong to the environment, not the vendor, but the exposure path still crosses organisational trust boundaries.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, IAM, and secrets management. It helps security and identity practitioners build the controls needed when software supply chain risk intersects with credential exposure.
Published by the NHIMG editorial team on August 2, 2026.
Updated on October 13, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org