Hijacked GitHub orgs are turning npm bots into wallet-key stealers

At a glance

What this is: A hijacked verified GitHub organisation was used to distribute malicious Polymarket bots that steal wallet keys, exfiltrate secrets, and open SSH backdoors.

Why it matters: It matters because developers often trust verified orgs, README instructions, and npm dependency trees, which means identity and supply-chain governance now overlap directly with secret exposure and workstation compromise.

By the numbers:

• The dev-protocol GitHub organisation had 568 followers before it was repurposed to distribute malicious trading bots.
• The organisation was flooded with scam repositories starting around February 26, 2026, while the oldest legitimate repos dated back to 2019.
• StepSecurity observed more than 20 Polymarket scam variants with inflated star counts and slight naming changes.

👉 Read StepSecurity’s analysis of the hijacked dev-protocol org and wallet-key theft

Context

Supply-chain abuse increasingly works by hijacking trust rather than breaking technology. In this case, attackers turned a verified GitHub organisation into a delivery channel for malicious npm packages and a convincing trading bot, which makes the primary risk credential theft and downstream wallet compromise rather than simple malware distribution.

For identity and access teams, the relevance is the same pattern seen in broader non-human identity abuse: trusted accounts, tokens, package scripts, and developer workstations become the control plane. Once a repository can execute install hooks and touch secret-bearing files, the boundary between software provenance and identity governance disappears.

This is not a fringe developer-only issue. Any programme that lets secrets live in local files, relies on unsigned dependency trust, or lacks build-time egress control is exposed to the same compromise pattern.

Key questions

Q: What breaks when npm package installation is allowed to execute lifecycle scripts by default?

A: A malicious dependency can run code before installation completes, which turns normal package resolution into a payload delivery mechanism. That breaks the assumption that package trust equals install safety. Teams need to treat lifecycle execution as a privilege boundary and restrict scripts that are not essential to the build.

Q: Why do verified GitHub organisations still pose supply-chain risk?

A: Verification and history can create false confidence, but they do not prove the current maintainer is trustworthy or that every new repository is legitimate. Attackers can hijack an organisation, reuse its reputation, and attach malicious code to a familiar name. That makes ownership changes and repository drift important security signals, not just platform housekeeping.

Q: How should security teams handle leaked secrets across developer workflows?

A: Treat every leaked secret as an identity incident, not just a code hygiene issue. Discover it across commits, pull requests, CI logs, and build artifacts, then revoke or rotate it quickly with an accountable owner. The goal is to reduce the credential’s usable lifetime and ensure the same secret cannot re-enter the workflow unnoticed.

Q: Who is accountable when a malicious package steals wallet keys from a developer machine?

A: Accountability usually spans software engineering, platform security, and identity governance because the failure crosses code provenance, secret storage, and execution policy. Organisations should map ownership for dependency approval, local secret handling, CI runner hardening, and incident response so that a package compromise cannot sit outside any control domain.

Technical breakdown

How typosquatted npm packages turn trusted installs into secret theft

The attack used package names that closely resembled legitimate libraries, then buried malicious logic in transitive dependencies and postinstall hooks. That matters because npm installation is not just code retrieval, it is code execution. When a package runs scripts automatically, the installer inherits the package author’s runtime privileges and network access. In this case, the payload searched for .env, id.json, and configuration files, then exfiltrated them to attacker-controlled infrastructure. The mechanism is classic supply-chain abuse, but the operational effect is identity compromise because the stolen material is credential material, not just source code.

Practical implication: treat npm install as an execution boundary and block scripts by default for untrusted packages.

Why a hijacked GitHub organisation increases social engineering success

A verified organisation with a long history, follower base, and legitimate legacy repositories creates borrowed credibility. Attackers do not need to invent trust from scratch when they can inherit it from an existing project identity and surrounding community signals such as stars, forks, and active issues. The malicious repo looked functional, connected to real APIs, and had enough polish to survive a quick review. That combination matters because developers often use repository reputation as a proxy for safety, even though reputation is not a control. The result is a trust attack on the developer decision process.

Practical implication: verify repository ownership changes, maintainer continuity, and package provenance before installing or running code.

How SSH backdoor installation and secret exfiltration reinforce each other

The second payload did more than steal files. It changed local system state by taking ownership of the SSH directory, enabling the firewall, and opening port 22, which creates a persistence path after the initial secret theft. That sequence shows a layered objective: harvest credentials first, then preserve access to the compromised machine. In governance terms, this is why secrets management and endpoint controls cannot be separated. If secrets live in local files and the build environment can execute privileged commands, the attacker can both extract identity material and maintain foothold on the workstation or runner.

Practical implication: monitor build runners for privileged process execution, SSH directory changes, and unexpected outbound connections.

Threat narrative

Attacker objective: The attacker aimed to steal wallet keys and other secrets, then preserve access to the victim system for follow-on control and monetisation.

1. Entry occurred when victims cloned a trusted-looking repository from a hijacked verified GitHub organisation and ran the supplied npm install workflow.
2. Credential access followed through typosquatted npm packages that searched local .env, id.json, and config files for wallet keys and API secrets.
3. Escalation and persistence were attempted through postinstall commands that took ownership of ~/.ssh, enabled the firewall, and opened port 22.
4. Impact was secret exfiltration, wallet compromise risk, and the creation of an SSH backdoor for continued attacker access.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Mastra npm Supply Chain Attack — Sapphire Sleet — North Korean Sapphire Sleet backdoors 144 AI npm packages in 88 minutes via supply chain attack on Mastra ecosystem.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Repository reputation is now an identity control, not a cosmetic signal. A verified badge, follower count, and old repository history can no longer be treated as sufficient evidence of trust. Attackers are exploiting the human tendency to equate social proof with software safety, which means developer platform governance now sits inside the broader identity boundary. Practitioners should treat repository ownership changes and maintainer continuity as access events, not just metadata.

Secret-bearing files are the easiest non-human identity to steal because they are already portable. Wallet keys, API keys, and configuration files often exist outside central secrets management, which makes them visible to malware and invisible to governance. This is the same control gap NHIs create elsewhere: credentials exist, are usable, and can be copied without lifecycle oversight. The named concept here is developer trust hijacking, where attacker control of a credible repository converts social trust into credential exposure.

Install-time execution has become a hidden privilege tier. Package scripts can run with more effective authority than many teams realise, especially in CI and developer workstations that allow network access and privileged operations. That breaks the assumption that dependency installation is a passive step. In practice, teams should align dependency execution review with least privilege, egress control, and script suppression policies.

SSH backdoors show why secret theft and endpoint compromise must be investigated together. The malware did not stop at exfiltration. It modified local access state to preserve future reach, which is a pattern security teams should recognise as credential abuse plus persistence. The control gap is not merely missing malware detection, it is failure to govern the machine identity of the build environment and the credentials stored on it.

Supply-chain attacks against developers are increasingly NHI attacks in disguise. The stolen material is not only code, it is the keys that represent non-human access across wallets, APIs, repositories, and infrastructure. That makes NHI lifecycle discipline relevant even in a software delivery context: if credentials are unmanaged, they become attacker-controlled identities the moment a package runs.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, followed by inadequate monitoring and logging at 37% and over-privileged accounts at 37%.
• For lifecycle control detail, see NHI Lifecycle Management Guide for provisioning, rotation, and offboarding patterns that reduce secret persistence.

What this signals

Developer trust hijacking: when a repository’s reputation is used as an access control substitute, the programme problem is not just malware detection but provenance governance. Teams should expect more attacks that combine social proof, typosquatting, and install-time execution to reach developer secrets before standard monitoring triggers.

The practical signal for identity and security programmes is that unmanaged secrets behave like portable NHIs. If a wallet key or API token sits in a local file, it can be copied, reused, and weaponised outside its intended lifecycle. That makes secret inventory, rotation, and offboarding the right control language, even in software supply-chain cases.

Build security needs to be treated as an identity boundary with egress constraints, not only as an application delivery concern. If a package can execute privileged commands during install, the runner’s access model matters as much as the code review process, and that is where governance should tighten first.

For practitioners

• Ban trusted-by-default package execution Require explicit approval for npm install scripts in untrusted repositories and use --ignore-scripts for new or externally sourced code.
• Separate wallet keys from developer files Remove wallet private keys and API secrets from .env, id.json, and config files on developer machines and CI runners.
• Watch for SSH state changes in runners Alert on modifications to ~/.ssh/authorized_keys, unexpected sudo use, and firewall changes such as opening port 22 during builds.
• Inspect package provenance before install Check for typosquatting, recently changed ownership, inflated stars, and suspicious postinstall hooks before cloning or installing dependencies.
• Constrain build egress by default Use an allow-list egress policy in CI so only required package registries and APIs can be reached during dependency installation.

Key takeaways

• This attack shows that trusted open-source infrastructure can be repurposed into a secret-stealing and backdoor-delivery channel without breaking the appearance of legitimacy.
• The compromise combined reputation abuse, typosquatted dependencies, wallet-key theft, and SSH persistence, which means the blast radius extended beyond code execution to identity compromise.
• Teams should harden package installation, remove secrets from local files, and treat developer workstations and CI runners as governed identity 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.
• Install-Time Execution: Install-time execution is code that runs while dependencies are being installed rather than when an application is launched. In supply chain attacks, this matters because the install phase often has access to the richest secrets in developer and CI environments, making it a high-value privilege boundary.
• Developer Trust Hijacking: Developer trust hijacking is the abuse of a legitimate repository, organisation, or maintainer identity to make malicious code look safe. It exploits social proof and workflow habits, then uses that borrowed credibility to deliver malware, steal secrets, or persist on developer systems.
• Secret-Bearing File: A file that stores credentials, tokens, keys, or other authentication material needed by software or operators. In practice, .env files are a common example because they are convenient for developers but risky when tools read them without explicit permission or containment.

What's in the full article

StepSecurity's full blog post covers the operational detail this post intentionally leaves for the source:

• The full process tree showing how npm install spawned the malicious postinstall hook and privileged shell commands.
• The decoded package behaviour behind levex-refa and lint-builder, including file search patterns and exfiltration endpoints.
• The exact GitHub Actions victim simulation and Harden-Runner telemetry used to confirm the attack chain in real time.
• The repository indicators of compromise, including malicious package names, domain indicators, and suspicious account patterns.

👉 StepSecurity’s full post covers the attack chain, malicious packages, and monitored simulation details.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle control. It helps practitioners translate identity policy into controls that fit modern development and cloud workflows.