Miasma Returns: Leo Platform Compromise Shows Why Package Detection Needs Context
By Sonatype Security Research Team
6 minute read time
TL;DR
-
The Shai-Hulud Miasma campaign has a fresh series of malicious packages following the compromise of the czirker maintainer account, affecting both the RStreams and Leo Platform ecosystems.
-
Sonatype is implicating 23 malicious package versions with this campaign. This wave builds directly on the Miasma playbook Sonatype recently reported: moving beyond obvious preinstall and postinstall scripts to abuse binding.gyp, steal credentials, validate access, and propagate through trusted package publishing workflows.
-
Organizations that installed affected versions should treat impacted developer workstations, CI/CD runners, build containers, and production-adjacent environments as potentially compromised. Remove malicious versions, investigate install-time execution, and rotate credentials only after persistence has been removed.
How the Leo Platform npm Compromise Turned Trust Into Execution
Attackers are not just publishing suspicious new packages and waiting for someone to typo their way into trouble. Increasingly, they are compromising the packages developers already trust.
On June 25, 2026, industry researchers began reporting another npm supply chain compromise tied to the Shai-Hulud Miasma malicious package campaign. Early reporting pointed to a compromised maintainer account used to publish malicious versions of packages associated with the Leo Platform ecosystem.
We have seen this pattern before: compromise a trusted maintainer or publishing workflow, modify legitimate packages, and let downstream automation do the rest.
What makes this wave especially important is where the execution happens. The malware continues the use of binding.gyp, a file normally associated with native Node.js add-ons. Instead of relying only on obvious lifecycle scripts in package.json, the malware can execute during installation through node-gyp.
Looking only at package metadata will not catch this kind of attack. A package can look clean at a glance, keep its legitimate name, and still execute malicious code before the application ever imports it.
That is the larger lesson from this campaign: a trusted package is only as trustworthy as its latest release.
The Leo Platform Compromise: What Sonatype Sees
Public reports differ on the exact number of malicious Leo ecosystem packages. Some early reporting listed 23 packages, while other technical writeups listed 20 confirmed malicious packages and omitted three pre-release or release-candidate Leo packages.
To help security teams avoid chasing false alarms and keep remediation workflows efficient, Sonatype's deep-dive analysis looked beyond initial metadata flags. Our preliminary analysis found that three packages included in some early public reporting do not appear to contain malicious code:
-
leo-connector-common@4.0.11-rc
-
leo-connector-postgres@4.0.19-beta
-
leo-connector-entity-table@3.0.22-rc
These packages should still be reviewed by affected teams because they are part of the surrounding incident activity. However, based on Sonatype's current analysis, they do not appear to carry the malicious payload observed in the confirmed Leo and RStreams packages.
Sonatype identified additional packages that were not included in public reports, but contain the same obfuscated payload, use the binding.gyp execution method, and were all published by an account that was likely compromised:
-
hexo-deployer-wrangler@1.0.4
-
hexo-shoka-swiper@0.1.10
-
prism-silq@1.0.1
Sonatype Security Research is continuing to track this campaign and will update findings as appropriate.
What Is Miasma Seeking to Steal?
Based on Sonatype's current analysis and prior Miasma reporting, affected organizations should review environments for exposure of:
-
GitHub tokens and GitHub Actions secrets
-
npm publishing tokens
-
Cloud credentials
-
CI/CD environment variables
-
Package registry credentials
-
SSH keys
-
Shell history and developer configuration files
-
Repository configuration
-
IDE and AI coding assistant configuration files
-
Build agent and runner secrets
This is not only a developer workstation problem. Dependency installation often happens inside CI/CD systems with access to secrets, deployment keys, registry tokens, and cloud credentials.
How Should Organizations Respond to the Shai-Hulud Miasma npm Attack?
Organizations that may be impacted by the latest Miasma campaign should investigate whether confirmed affected versions were installed in developer workstations, CI/CD runners, build agents, internal package mirrors, dependency caches, container images, lockfiles, or production-adjacent systems.
Start by reviewing:
-
package.json and package-lock.json
-
yarn.lock
-
pnpm-lock.yaml
-
CI/CD dependency installation and container build logs
-
Package manager caches
-
Internal repository manager logs
-
SBOMs and dependency manifests
-
npm proxy or firewall telemetry
If a confirmed malicious package version was installed, do not simply remove the package and move on. Preserve logs, isolate affected systems, remove malicious versions from manifests and caches, regenerate lockfiles from known-good versions, and inspect install logs for node-gyp, binding.gyp, obfuscated JavaScript execution, unexpected temporary files, and outbound network activity.
Credential rotation is essential, but timing matters. Rotate GitHub, npm, cloud, CI/CD, package registry, SSH, and other exposed credentials only after affected environments have been investigated and cleaned. If persistence remains, newly rotated credentials may be exposed again.
What Does It Reveal About npm Supply Chain Risk?
This incident reinforces a pattern Sonatype continues to track across npm attacks: attackers are not simply publishing suspicious new packages. They are compromising trusted packages, trusted maintainers, and trusted workflows.
A package name can be legitimate while a specific version is malicious. A maintainer account can be trustworthy until its token is stolen. A package can have years of clean history and become dangerous in a single release.
The Leo Platform compromise also shows how quickly campaigns evolve around the security community’s response. Once defenders learn one marker, attackers shift strings. Once defenders inspect postinstall, attackers move execution to binding.gyp. Once researchers publish detections, noisy decoys and vendor-referencing packages may appear.
Security teams need to hunt for behavior, not branding.
Trust Is the Attack Vector; Developers Are the Target
The Leo Platform compromise is another reminder that open source risk is no longer limited to suspicious new packages or obvious typosquats. Increasingly, attackers are targeting the packages, maintainers, and publishing workflows developers already trust.
That changes how organizations need to think about dependency security. A package with a legitimate name, a clean history, and an established user base can still become malicious in a single compromised release. Security teams need visibility into what each version does at install time, not just whether the package has been trusted before.
Sonatype Security Research is continuing to analyze the Leo Platform compromise, related Shai-Hulud Miasma activity, and packages that may have been missed or misclassified in early public reporting.
Organizations should treat confirmed installations as potential compromise events, review dependency and build telemetry, and rotate credentials only after affected environments have been investigated and cleaned.
Written by Sonatype Security Research Team
Sonatype's Security Research Team is focused on bringing real-time, in-depth intelligence and actionable information about open source and third party vulnerabilities to Sonatype customers.
Explore All Posts by Sonatype Security Research TeamTags
