Topic starter
19/08/2026 3:44 pm
TL;DR: A hijacked verified GitHub organisation was used to host malicious Polymarket trading bots that hid typosquatted npm packages, exfiltrated wallet keys and configuration files, and installed an SSH backdoor during installation and runtime, according to StepSecurity. The case shows how trusted open-source infrastructure can be repurposed into a supply-chain delivery path for NHI and developer secrets.
Editorial analysis by NHI Mgmt Group, based on content published by StepSecurity: “Malicious Polymarket Bot Hides in Hijacked dev-protocol GitHub Org and Steals Wallet Keys”.
By the numbers:
- The dev-protocol GitHub organization had 568 followers before it was abused to host scam repos.
- The organization now has 830 repositories, of which 664 are forks.
Key questions
Q: What breaks when a verified GitHub organisation is hijacked for npm supply-chain attacks?
A: Repository trust breaks first, because the badge and follower history can mask malicious packages inside otherwise believable projects.
Q: Why do malicious npm packages often target wallet keys and API secrets together?
A: Because those secrets usually live side by side in local configuration files and both provide reusable access.
Q: What signs show that an npm install has already become a persistence event?
A: Look for unexpected postinstall activity, outbound traffic to unfamiliar domains, changes to ~/.ssh/authorized_keys, firewall rule edits, and any attempt to open port 22.
Practitioner guidance
- Audit install-time execution paths Review every npm dependency for postinstall, preinstall, and prepare hooks before allowing it into developer or CI environments.
- Separate wallet keys from local config files Move signing keys out of .env, id.json, and similar files that can be searched and exfiltrated by dependency malware.
- Monitor SSH state after package installs Check ~/.ssh/authorized_keys, firewall rules, and port 22 exposure after any suspicious package installation or bot execution.
Bottom line: A hijacked verified GitHub organisation can become a delivery channel for malicious npm packages that steal wallet keys and modify the host during install.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
19/08/2026 4:22 pm
Trusted repository identity is now part of the secrets attack surface. This case works because the attackers did not need to invent credibility, they inherited it by hijacking a verified GitHub organisation with an existing history and follower base. That changes how teams should think about trust in open-source supply chains: repository reputation can no longer be treated as evidence of code safety. Practitioners need controls that evaluate package behaviour, not just project appearance.
A question worth separating out:
Q: Should teams trust a working bot if its dependencies look suspicious?
A: No. Functionality can be deliberate cover, and a tool that appears to work normally may already have stolen secrets or modified the host. Teams should verify dependency provenance, block unsafe install scripts, and assume hidden behaviour until the package chain is proven clean.
👉 Read our full editorial: Hijacked GitHub orgs are turning npm bots into wallet-key stealers