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.
At a glance
What this is: A hijacked verified GitHub organisation was repurposed to distribute malicious npm-powered Polymarket bots that stole wallet keys, exfiltrated local secrets, and installed SSH backdoor behaviour.
Why it matters: It matters because identity and secrets governance now has to account for trusted repositories, dependency chains, and runtime installation hooks that can weaponise developer wallets and machine credentials.
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.
- The newest repos were created after February 2026 and the attacker published more than 20 Polymarket scam variants.
Context
A verified GitHub organisation can still become a distribution mechanism for malicious code when account control, repository history, and social trust are all abused together. In this case, the primary security problem is not just malware in npm packages, but the way trusted open-source infrastructure can mask credential theft and persistence.
The article also sits at the intersection of NHI governance and developer security because the payload targets wallet private keys, API keys, and SSH access used by people and automation alike. That makes the incident relevant to IAM, secrets management, and software supply-chain controls, not only to cryptocurrency developers.
The pattern is not unusual for modern supply-chain attacks: a legitimate-looking project, malicious transitive dependencies, and runtime actions that continue after installation. What makes it more dangerous is that the bot still works, so victims have little behavioural signal that exfiltration and backdoor setup already happened.
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. From there, dependency execution becomes the attack path, and teams lose the ability to assume that a familiar org name means safe code or safe installation behaviour.
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. If an attacker can read .env, id.json, or similar files, they often get signing authority, service access, and the ability to move from one compromise target to another without needing another exploit.
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. Those are not normal package behaviours and usually indicate the install path is being used to establish durable access.
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.
Technical breakdown
Typosquatted npm dependencies as the initial delivery path
The initial compromise path is dependency substitution. Two packages, ts-bign and big-nunber, are designed to look like legitimate libraries while pulling in malicious transitive dependencies. That matters because package managers resolve trust before code review in many workflows, so a believable name, copied README, and functioning surface can conceal a payload until installation or import time. In this case the malicious code is not only declared in package metadata, it is also imported directly in source files, which guarantees execution when the bot starts. That creates two activation points: install-time and runtime. Practical implication: treat package identity and dependency resolution as part of the attack surface, not just the code body.
Practical implication: Block untrusted package execution and inspect transitive dependencies before install-time code can run.
Postinstall hooks and source imports create dual execution windows
The malware uses both npm lifecycle hooks and explicit source imports, which gives it two separate chances to execute. A postinstall script runs automatically during npm install, before a developer may ever launch the application. Source-level imports then trigger a second stage when the program starts, which is especially effective in bots and CLIs where users expect network activity as part of normal function. This pattern matters because many teams think of dependency risk as a one-time install problem, when in reality lifecycle scripts and runtime imports can each carry separate malicious actions. Practical implication: review postinstall hooks as seriously as application code, and restrict scripts during installation of untrusted packages.
Practical implication: Disable untrusted install scripts and monitor for runtime imports that activate hidden payloads.
Wallet key theft and SSH backdoor setup show credential abuse plus persistence
The payload does more than steal files. It searches for .env, id.json, and config files that often contain wallet keys or operational secrets, then exfiltrates them to attacker-controlled endpoints. The second-stage installer also takes ownership of the SSH directory, enables the firewall, and opens port 22, which turns a credential theft event into host persistence. That combination is important because it shows the attacker is planning both immediate reuse of stolen secrets and longer-term access to the compromised machine. Practical implication: secrets handling and endpoint control must be linked, because exposed wallet keys and SSH state are part of the same compromise path.
Practical implication: Tie secret scanning to host integrity checks so stolen credentials and backdoor changes are investigated together.
Threat narrative
Attacker objective: The attackers want wallet private keys, API secrets, and a backdoored development host they can reuse after the initial install.
- Entry occurs when attackers hijack a verified GitHub organisation and publish polished repos with typosquatted npm dependencies that look like normal developer tooling.
- Credential access happens when the malicious packages search for .env, id.json, and config files, then exfiltrate wallet keys and API secrets to attacker-controlled endpoints.
- Escalation and persistence occur when the install-time payload takes ownership of ~/.ssh, enables the firewall, and opens port 22 for inbound access.
- Impact is secret theft plus durable machine access, with the working bot continuing to connect to real Polymarket APIs while the victim's credentials are already compromised.
Breaches seen in the wild
- Laravel-Lang Composer compromise 2026: A stolen GitHub PAT let an attacker rewrite every Laravel-Lang release tag in May 2026, serving a PHP stealer of cloud, CI and SSH credentials.
- 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).
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
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.
Dependency execution has become an identity and lifecycle problem, not only a malware problem. When install hooks and runtime imports can both execute attacker code, the boundary between software delivery and credential compromise collapses. That is especially relevant for NHI governance because the payload is targeting wallet keys, API keys, and SSH state, which are machine-usable identities in practice. Organisations should treat package install paths as privileged execution paths.
Credential exposure now extends beyond secrets scanning into host persistence. The distinctive failure mode here is not merely that secrets existed on disk, but that the attacker paired theft with SSH directory takeover and firewall changes. That means the governance gap is standing trust in developer machines and CI runners after package execution begins. For security teams, the lesson is to assume install-time compromise can alter both secrets and access paths.
Wallet keys behave like high-value NHIs when they live in developer workflows. The article shows that consumer-facing trading tools can still create enterprise-style identity risk when private keys, API tokens, and configuration files are handled locally. Once those credentials are stored in reusable files, the distinction between developer convenience and privileged access disappears. NHI governance therefore has to cover any workflow that turns local files into reusable signing authority.
Supply-chain trust inversion: this attack illustrates a failure mode where the most trusted surface becomes the delivery path for the least trusted code. The attackers used verified history, realistic bot behaviour, and deceptive dependency names to invert normal trust assumptions. That is exactly the sort of pattern that should trigger stricter package admission, runtime egress control, and credential containment in development environments.
What this signals
Trusted package names are no longer enough to establish software trust. In development and CI environments, teams should assume that polished repositories can still hide malicious install-time behaviour, especially when typosquatting and copied readmes are used to borrow credibility. The practical response is to move trust decisions earlier, before installation and before runtime imports can execute.
Developer secrets need the same governance discipline as production credentials. When wallet keys, API tokens, and SSH material are stored in local files, an npm compromise can turn a routine install into a full access event. Security teams should align secrets handling with endpoint monitoring so that exfiltration and backdoor setup are detected as one incident path.
Behavioural controls matter more than reputation in this threat pattern. Allow-listed registries, blocked install scripts, egress monitoring, and host-integrity checks are more reliable than follower counts or verified badges when the objective is to stop supply-chain abuse. That is the control shift this kind of attack forces on software teams.
For practitioners
- 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.
- Block unexpected outbound build traffic Alert on non-registry connections, especially Vercel-hosted endpoints and IP fingerprinting calls during npm install or bot startup.
- Treat verified orgs as untrusted until behaviour is validated Verify repository ownership changes, commit provenance, and dependency graphs before trusting a project that looks established.
Key takeaways
- A hijacked verified GitHub organisation can become a delivery channel for malicious npm packages that steal wallet keys and modify the host during install.
- The attack chained dependency deception, file theft, and SSH persistence, which means secrets governance and endpoint integrity must be reviewed together.
- Teams should treat install-time scripts, runtime imports, and local credential files as part of the same compromise surface.
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 NIST SP 800-53 Rev 5, CIS Controls v8 and CSA Cloud Controls Matrix set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The attack steals wallet keys and secrets from local files, which is direct secret leakage. |
| NHI-03 — Vulnerable Third-Party NHI | The malicious npm packages act as third-party NHIs embedded in a trusted supply chain. | |
| NHI-07 — Long-Lived Secrets | Wallet keys and API secrets stored in files create reusable access that survives a single install event. | |
| Recommendation — Scan repositories, images, and build logs for exposed NHI secrets and revoke any leaked credentials immediately. Inventory third-party packages that can execute in your build path and quarantine any with suspicious lifecycle behaviour. Replace long-lived secrets in developer workflows with short-lived credentials and scoped signing controls. | ||
| MITRE ATT&CK | TA0006; TA0003; TA0040 — Credential Access; Persistence; Impact | The chain combines credential theft, persistence setup, and operational impact on the host. |
| Recommendation — Map suspicious npm lifecycle activity to credential access and persistence techniques, then isolate affected systems. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The incident hinges on stolen authenticators and secret material stored in files. |
| Recommendation — Apply authenticator lifecycle controls to rotate exposed secrets and remove compromised credentials from workflows. | ||
| CIS Controls v8 | CIS-5 — Account Management | The attack abuses account and access material in config files and SSH state. |
| Recommendation — Audit account and key material used by development tooling and disable any accounts or keys that are no longer needed. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Cloud-hosted build and secret access controls are central to containing this supply-chain abuse. |
| Recommendation — Enforce IAM governance over build identities, secret access, and package execution privileges in cloud and CI environments. | ||
Key terms
- Typosquat Package: A typosquat package is a malicious or misleading package name designed to resemble a legitimate dependency. Attackers rely on typing mistakes, autocomplete, or familiarity to get developers to install it, then use the trusted package manager path to deliver payloads or steal data.
- Preinstall Hook: A preinstall hook is package code that runs before an application installs or starts. In supply-chain attacks, it becomes a hidden execution point that can steal secrets, alter environments, or drop further payloads before normal controls see the package's behaviour.
- Verified GitHub Organisation: A verified GitHub organisation is an account that GitHub has associated with a real entity or project. Verification improves trust signals, but it does not guarantee code safety or prevent takeover, so it should be treated as a reputation marker rather than a security control.
- Wallet Private Key: A wallet private key is the secret that authorizes control of a cryptocurrency wallet. Unlike a password, it cannot be reset while preserving the same account identity. Anyone who obtains it can create valid signatures, approve transactions, and move assets associated with the wallet.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and workload identity for practitioners who need to tighten control over machine-usable access. It helps security teams connect identity governance to the operational reality of secrets, credentials, and delegated access.
Published by the NHIMG editorial team on August 19, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org