Mass npm Supply Chain Attack: 20 Leo Platform Packages Compromised

What it is

StepSecurity's analysis of a targeted npm supply-chain attack on the Leo Platform ecosystem. On 2026-06-24 an attacker used stolen maintainer credentials to publish malicious versions of 20 packages (~13,600 downloads/week combined) in a burst under 3 seconds, timestamped 2026-06-24T23:04:55Z. StepSecurity analyzed leo-logger@1.0.8 in full and spot-checked leo-sdk@6.0.19. It is attributed to the same actor behind the Miasma campaign (57 packages, published 2026-06-03) — 21 days earlier, quieter and more targeted, but structurally identical.

How it works

The summary covers the delivery chain; the page adds the identifying fingerprints and additional capabilities:

• Obfuscation chain is specifically ROT-N cipher → AES-128-GCM → obfuscator.io, and the payload downloads Bun v1.3.13 from a fixed URL. The identical binding.gyp hook syntax, Bun URL, and obfuscation structure are what tie both campaigns to one actor.
• Runner memory theft: locates the GitHub Actions Runner.Worker process via /proc/{pid}/cmdline, then reads /proc/{pid}/mem directly to recover secrets masked in workflow logs.
• Two capabilities not in the summary — Workflow injection: modifies Actions workflow files to request id-token: write and reference attacker-controlled pinned action SHAs. Privilege escalation: on GitHub-hosted runners writes runner ALL=(ALL) NOPASSWD:ALL for passwordless sudo.
• Credential sweep targets are broad: AWS (IMDS, Secrets Manager, SSM, ECS), GCP, Azure (Key Vault, federated creds), HashiCorp Vault (10+ token locations), Kubernetes, npm, PyPI, RubyGems, JFrog, GitHub PATs, and 1Password.

Preconditions / Affected

Any of the 20 listed Leo Platform packages at the compromised versions, installed in an environment where npm install runs the install hook — CI/CD runners are the primary target. Exfiltration uses the victim's own GitHub token via the GraphQL API to commit to a dead-drop repo, so no attacker-controlled domain is ever contacted — egress filtering will not catch it.

What to do

• Detection heuristic the page states plainly: treat as suspicious any package that ships a binding.gyp file but has no C++ sources and no .node binary output. The Phantom Gyp technique hides execution in node-gyp's <!(...)> shell expansion inside the sources array, so nothing appears in the scripts block of package.json.
• Runtime detection signal: the anomalous process chain is node-gyp spawning curl, unzip, and bun, plus an unauthorized /proc/*/mem read. Harden-Runner terminates the run on this pattern.
• Rotate any secrets exposed to affected CI runs; audit workflow files for injected id-token: write and unexpected pinned action SHAs; check for the sudoers modification on self-hosted runners.
• A registry cooldown on newly published versions blocks the ingestion window.

Caveats

Only leo-logger@1.0.8 was analyzed in full; the rest of the 20 were confirmed by spot-check and shared toolkit fingerprints. The full IOC list and the complete package-and-version table live in the linked Miasma post and StepSecurity Threat Center, not in this page's excerpt.