Summary

On June 24, 2026, an attacker published malicious versions of 20 npm packages belonging to the Leo Platform ecosystem in a coordinated burst spanning less than three seconds. All 20 packages carry an identical CI/CD attack toolkit that steals secrets from GitHub Actions runners, cloud credential stores, package registries, and password managers, then exfiltrates them via the victim's own GitHub token. Together these packages receive approximately 13,600 downloads per week.

We analyzed leo-logger@1.0.8 in full and spot-checked leo-sdk@6.0.19 to confirm the campaign scope. The attack uses the same toolkit and delivery mechanism we documented in our earlier post on the Miasma campaign: a "Phantom Gyp" binding.gyp install hook, a three-layer obfuscation chain (ROT-N cipher, AES-128-GCM, obfuscator.io), and Bun runtime evasion. For a full technical breakdown of the attack chain, see that post. This report focuses on the Leo Platform campaign specifics: the 20 affected packages, the coordinated publish, and remediation steps.

All 20 packages were published within a 3-second window at 2026-06-24T23:04:55Z, confirming a single automated operation against the Leo Platform maintainer accounts. The payload is structurally identical to the Miasma campaign published June 3, 2026, sharing the same binding.gyp hook syntax, the same three-layer obfuscation chain, and the same Bun v1.3.13 download URL. This seems to be the same threat actor targeting a new ecosystem, 21 days after Miasma.

Affected Packages

The following 20 packages are confirmed malicious at the listed versions. All were published simultaneously by an unauthorized actor who gained access to the Leo Platform maintainer credentials.

‍

Connection to the Miasma Campaign

On June 3, 2026 we published a detailed technical analysis of the Miasma campaign, which compromised 57 npm packages across 286+ versions using the same toolkit. The Leo Platform attack is structurally identical:

The Leo Platform operation is more targeted and quieter than Miasma. It focuses on a single maintained ecosystem rather than carpet-bombing across maintainer accounts, and the publish window (3 seconds vs. under 2 hours) suggests the same automated payload factory operating with improved tooling. The binding.gyp hook syntax, the Bun download URL, and the three-layer obfuscation structure are fingerprints that tie both operations to the same actor.

The "Phantom Gyp" technique uses the node-gyp <!(...)> shell expansion inside the sources array to execute arbitrary commands at install time without declaring any entry in the scripts block of package.json. Any package that ships a binding.gyp file but has no C++ sources and no .node binary output should be treated as suspicious. For a full technical walkthrough of the obfuscation chain and payload capabilities, see our Miasma analysis.

What the Payload Does

The payload capabilities are documented in detail in the Miasma post. In summary, the toolkit does the following on every install:

• Runner process memory extraction: Locates the GitHub Actions Runner.Worker process via /proc/{pid}/cmdline, then reads /proc/{pid}/mem directly to recover secrets that are masked in workflow logs and invisible to child processes.
• Multi-cloud credential sweep: AWS (IMDS, Secrets Manager, SSM, ECS), GCP (metadata service, service account keys), Azure (managed identity, Key Vault, federated credentials), HashiCorp Vault (10+ token file locations), Kubernetes (service account token), npm, PyPI, RubyGems, JFrog, GitHub PATs, and 1Password.
• GitHub dead-drop exfiltration: Stolen credentials are encrypted and committed to GitHub repositories via the GitHub GraphQL API using the victim's own token. No external attacker-controlled domain is contacted.
• Supply chain worm: If an npm token is found, the payload publishes malicious versions of any package the victim has publish rights to via the bypass_2fa API mechanism, without triggering two-factor authentication.
• Workflow injection: GitHub Actions workflow files are modified to request id-token: write permission and add steps referencing attacker-controlled pinned action SHAs.
• Privilege escalation: On GitHub-hosted runners, the payload writes runner ALL=(ALL) NOPASSWD:ALL to grant passwordless sudo access.

Indicators of Compromise

‍

For StepSecurity Customers

Threat Center Alert

StepSecurity has published a threat intel alert in the Threat Center with all relevant links to check if your organization is affected. The alert includes the full attack summary, technical analysis of the Phantom Gyp technique, IOCs, all affected packages and malicious versions, and remediation steps, so teams have everything needed to triage and respond immediately. Threat Center alerts are delivered directly into existing SIEM workflows for real-time visibility.

Harden-Runner

Harden-Runner is a purpose-built security agent for CI/CD runners. It monitors all network events, process executions, file access, and outbound network connections at the step level in GitHub Actions, providing full runtime visibility into what happens during every workflow step, including npm install.

Harden-Runner detects the anomalous process chain (node-gyp spawning curl, unzip, and bun) and the unauthorized memory read, immediately initiating lockdown mode. The workflow run is terminated, preventing any secrets from being extracted.

Link to the run : https://app.stepsecurity.io/github/actions-security-demo/test-comp/actions/runs/28155317636

Secure Registry

StepSecurity Secure Registry provides each enterprise customer with a dedicated, policy-enforced npm registry that sits between your existing package manager (such as JFrog Artifactory) and the public npm registry. Instead of fetching packages directly from registry.npmjs.org, your infrastructure routes requests through your StepSecurity registry, which applies configurable security policies before serving any package.

The primary defense here is the cooldown period. Newly published package versions are held for a configurable window before being served to any developer machine or CI/CD pipeline. When the compromised Miasma packages were published to npm, including @vapi-ai/server-sdk, ai-sdk-ollama, and dozens of packages in the jagreehal ecosystem, Secure Registry customers were never exposed.

Detect Compromised Developer Machines

StepSecurity Dev Machine Guard gives security teams real-time visibility into npm packages installed across every enrolled developer device. When a malicious package is identified, teams can immediately search by package name and version to discover all impacted machines.

npm Package Cooldown Check

Newly published npm packages are temporarily blocked during a configurable cooldown window. When a PR introduces or updates to a recently published version, the check automatically fails. Since most malicious packages are identified within hours, this creates a crucial safety buffer. In this case, 57 packages across 286+ malicious versions were published in a rolling campaign lasting under two hours on June 3, so any PR updating to an affected version during the cooldown period would have been blocked automatically.

‍

npm Package Compromised Updates Check

StepSecurity maintains a real-time database of known malicious and high-risk npm packages, updated continuously, often before official CVEs are filed. If a PR attempts to introduce a compromised package, the check fails and the merge is blocked. All compromised versions from this Miasma campaign, including @vapi-ai/server-sdk, ai-sdk-ollama, and the full jagreehal package family, were added to this database within minutes of detection.

‍

npm Package Search

Search across all PRs in all repositories across your organization to find where a specific package was introduced. When a compromised package is discovered, instantly understand the blast radius: which repos, which PRs, and which teams are affected. This works across pull requests, default branches, and dev machines.

‍

‍

‍

‍