Topic starter
02/08/2026 9:47 am
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.
Editorial analysis by NHI Mgmt Group, based on content published by OXSecurity: “Malware-Slop: Crypto Stealer Impersonating Polymarket Exposes Its Own Credentials”.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: 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.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 12:39 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Polymarket-kit npm supply chain attack exposes cloud and wallet data