Post

Inside Miasma: How One Compromised npm Account Turned Into a Multi-Ecosystem Supply Chain Attack

Posted
Preview Image
By dollarboysushil
10 min read
Inside Miasma: How One Compromised npm Account Turned Into a Multi-Ecosystem Supply Chain Attack

Executive Summary

In June 2026, researchers uncovered another evolution of the Mini Shai-Hulud malware family, dubbed Miasma. Unlike traditional npm malware that targets a handful of packages, this campaign showed how compromising a single piece of developer infrastructure can rapidly spread across multiple ecosystems: npm, GitHub Actions, and even Go modules.

The attackers didn’t target end users. They targeted publishers, CI/CD pipelines, and the trust mechanisms that let software move from a developer’s laptop to production without anyone re-checking it along the way. No CVE exists for any of it, because nothing about the affected code was ever flawed. The entry point was a stolen credential, not a vulnerability.

Affected Packages (npm and Go)

Package Compromised version
hexo-deployer-wrangler 1.0.4
hexo-shoka-swiper 0.1.10
leo-auth 4.0.6
leo-aws 2.0.4
leo-cache 1.0.2
leo-cdk-lib 0.0.2
leo-cli 3.0.3
leo-config 1.1.1
leo-connector-elasticsearch 2.0.6
leo-connector-mongo 3.0.8
leo-connector-mysql 3.0.3
leo-connector-oracle 2.0.1
leo-connector-redshift 3.0.6
leo-cron 2.0.2
leo-logger 1.0.8
leo-sdk 6.0.19
leo-streams 2.0.1
prism-silq 1.0.1
rstreams-metrics 2.0.2
rstreams-shard-util 1.0.1
serverless-convention 2.0.4
serverless-leo 3.0.14
solo-nav 1.0.1
github.com/verana-labs/verana-blockchain (Go) v0.10.1-dev.20

Note: socket.dev is doing continuous investigation, recent update / findings are added on https://socket.dev/supply-chain-attacks/miasma-mini-shai-hulud-supply-chain-attack

If your dependency tree includes any of these at the listed versions (or earlier compromised waves from the same campaign in early June), treat the environment as potentially compromised and follow the immediate remediation steps above.

Timeline

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

June 24, 2026, 15:39 UTC
   ↓
LeoPlatform maintainer account compromised
   ↓
23 malicious package versions published (3-second window)
   ↓
binding.gyp payload executes on install
   ↓
Developer + CI/CD credentials stolen
   ↓
GitHub Actions workflow ("Run Copilot") deployed
   ↓
Stolen secrets exfiltrated to public GitHub repos
   ↓
Go module (Verana Blockchain) compromised via a related technique
   ↓
Researchers at Socket, Wiz, Sonatype, and others identify and disclose the campaign

This is wave four of the same campaign in under a month, it first surfaced against Red Hat’s npm namespace on June 1, then a 57-package wave on June 3, then this LeoPlatform/Go wave on June 24–25.

What Actually Happened

  • A maintainer of the LeoPlatform npm ecosystem had their account credentials or npm token stolen, most likely by an infostealer.
  • The attacker used that stolen access to publish trojanized versions of packages the maintainer already legitimately owned, nothing needed to be “hacked” in the traditional sense, because the attacker already had a trusted publishing identity.
  • Anyone who installed one of those versions ran a hidden payload that stole their own credentials.
  • Some of those stolen credentials belonged to GitHub Actions environments, which let the attacker plant a malicious workflow and steal CI/CD secrets directly out of the runner.
  • Separately, a Go module was compromised using a related but distinct technique, showing the campaign isn’t tied to any one language or package manager.
  • The whole thing was discovered because multiple independent security research teams were watching for exactly this pattern from earlier waves of the same campaign.

Technical Breakdown

Stage 1 : Compromised maintainer The npm account “czirker,” associated with LeoPlatform, was compromised, most likely through leaked credentials or a token lifted by an infostealer already running on the maintainer’s machine.

Stage 2 : Malicious package published Using the stolen token, the attacker published 23 malicious package versions across the LeoPlatform and RStreams ecosystems in a six-second window. That speed points to a scripted, automated publishing tool, not a person manually uploading files.

Stage 3 : Install-time execution This is the clever part. Most malicious npm packages get caught because scanners watch the preinstall and postinstall script fields in package.json. Miasma skips those entirely and instead adds a binding.gyp file, the configuration Node.js uses to compile native modules during install. Because binding.gyp is a completely normal part of building native add-ons, it runs code during npm install without ever touching the fields most tooling is watching.

This is also why the common advice to run npm install --ignore-scripts doesn’t fully protect you here: that flag suppresses lifecycle scripts, but the native module build step that binding.gyp triggers isn’t a lifecycle script in the same sense, and can still execute.

Stage 4 : Secrets collection Once running, the payload harvests a broad set of credentials, including:

  • npm and PyPI tokens
  • GitHub Personal Access Tokens and GitHub OIDC tokens
  • AWS, Azure, and GCP credentials
  • SSH keys
  • Configuration and credential paths for Claude Code, Cursor, and other AI coding assistants
  • OpenAI API keys
  • Slack and Twilio tokens, Docker auth files, Kubernetes configs, Vault data, and shell history

Stage 5 : GitHub abuse The malware drops a GitHub Actions workflow (seen under the name “Run Copilot”) that pulls secrets directly out of CI runner memory during execution. Stolen data is encrypted and pushed to newly created public GitHub repositories acting as dead drops, at the time of writing, 550+ repositories carry the campaign’s exfiltration marker. A related incident on the same day saw an attacker force-push a malicious commit to a widely used GitHub Action and redirect version tags to point at it, meaning any workflow that ran against those tags after that point executed the attacker’s payload directly inside the GitHub Actions runner.

Stage 6 : Propagation

1
2
3
4
5
6
7
8
9
10
11

Developer machine compromised
   ↓
Developer's GitHub credentials stolen
   ↓
CI/CD pipeline secrets harvested from the runner
   ↓
Stolen npm token used to publish more malicious packages
   ↓
More developers install the compromised packages
   ↓
(repeat)

Each successful compromise becomes the launchpad for the next one. That’s what makes this a self-propagating campaign rather than a single incident.

5. Why This Attack Is Different

Old supply-chain attacks Miasma
Single package Entire ecosystem
Cryptocurrency theft Broad credential theft
One language Multiple languages (npm, now Go)
One maintainer Developer infrastructure as a whole
Static malware Self-propagating, evolving between waves

Earlier npm supply chain incidents were largely smash-and-grab: compromise a package, steal wallet keys or session tokens, move on. Miasma behaves more like a worm with a business model, it treats every successful infection as fuel for the next wave, and it’s demonstrably still evolving three-plus weeks and four separate waves in.

6. Why GitHub Actions Became a Target

GitHub Actions sits at a uniquely valuable point in the software supply chain: it holds OIDC tokens used for trusted, credential-less publishing to cloud providers and registries, it stores long-lived CI secrets, and it has automated, unattended execution by design. Compromising a CI runner doesn’t just expose one developer’s laptop, it exposes every deployment pipeline, registry publish, and cloud credential that workflow touches. That’s a far bigger blast radius than any individual developer’s local environment, which is exactly why the campaign built dedicated tooling to specifically target it.

7. Why Expanding Into Go Matters

Most coverage of this campaign focused on npm, since that’s where the majority of the packages live. But the Go module compromise is arguably the most important detail in the entire story, and it’s the one most write-ups skip past.

The Go sample doesn’t use binding.gyp. It doesn’t rely on Go’s module resolution or build mechanisms at all. Instead, a developer who simply clones the repository or opens it in a trusted IDE or AI coding assistant can trigger the payload through project configuration alone.

That tells you something important: the attackers aren’t fundamentally interested in JavaScript, or npm, or any specific package manager’s mechanics. They’re interested in developers, wherever developers place trust in automated tooling, whether that’s an install script, a build step, or an IDE opening a folder. Language doesn’t matter. Developer credentials do.

8. The Bigger Lesson

Old thinking:

1
2
3
4
5

We scan dependencies
   ↓
We patch known CVEs
   ↓
We're safe

Modern reality:

1
2
3
4
5
6
7
8
9

A developer is compromised
   ↓
CI/CD is compromised
   ↓
A legitimate package is published with malicious code
   ↓
Every downstream consumer installs it
   ↓
No CVE is ever required at any step

Dependency scanning answers the question “does this code have a known flaw.” Miasma exposes a completely different question that most security programs aren’t set up to answer at all: “do I trust the humans and automated systems that are allowed to publish code into my environment, right now, today.”

9. Detection Opportunities

Rather than “how to stop it” it’s more useful to ask where a defender realistically had a chance to notice something was wrong:

1
2
3
4
5
6
7
8
9
10
11

Unusual developer machine activity
   ↓
Unexpected new GitHub Actions workflow appears in a repo
   ↓
OIDC token used somewhere it's never been used before
   ↓
A package version publishes far faster than a human plausibly could
   ↓
Outbound traffic to a newly created GitHub repository
   ↓
A dependency's published hash doesn't match its source repository

Every one of these is a detectable signal. None of them require a CVE database. They require actually watching how trust and access move through your environment over time, not just what’s listed in a manifest file.

10. What Organizations Should Do

Immediate

  • Rotate credentials for any environment that installed an affected package, but only after removing the malicious version and confirming persistence is gone, not before
  • Update or remove affected package versions across lockfiles, caches, containers, and CI runners, not just the top-level manifest
  • Revoke and reissue any GitHub tokens, OIDC configurations, or npm tokens that may have been exposed
  • Pin GitHub Actions by commit hash instead of mutable version tags

Medium-term

  • Introduce package allowlists for what’s permitted in CI/CD and production builds
  • Require package provenance and signing where available
  • Maintain a real Software Bill of Materials (SBOM), not a point-in-time snapshot
  • Add a cooldown window before newly published package versions are trusted in a build

Long-term

  • Continuous validation of what’s actually running in your environment, not periodic audits
  • Repository and CI/CD monitoring for unexpected workflow changes or publishing behavior
  • Ongoing attack path analysis, not just “is this package vulnerable” but “what could someone reach if this package were malicious”
  • Developer identity monitoring, since in this campaign the identity was the actual attack surface

11. Why This Matters to Penetrify

Miasma wasn’t an npm problem. It was an identity problem. A CI/CD problem. A trust problem. An attack-path problem.

The attackers didn’t discover a vulnerability. They discovered a path from a single developer’s workstation to thousands of downstream systems, and that path existed entirely inside relationships that most security programs never actually monitor: which humans can publish code, which tokens can trigger a deployment, which workflows run unattended with real access to production.

That’s exactly why modern software supply chain security needs to move beyond dependency scanning and toward continuously understanding how trust relationships evolve across repositories, build pipelines, identities, and production environments, not just what CVEs exist in a manifest file.

Sources

Writeups, HackTheBox, cve
Pterodactyl htb linux ctf cve CVE-2025-49132
This post is licensed under CC BY 4.0 by the author.