Researchers Disclose "Miasma" Supply-Chain Wave Across 20+ npm Packages and GitHub Actions

Another JavaScript-ecosystem supply-chain disclosure puts developer-secret rotation and GitHub Actions auditing back at the top of the defender to-do list — this time as a fresh wave of the ongoing Miasma cluster.

SAN FRANCISCO, CALIFORNIA — Researchers on June 28, 2026 detailed a fresh wave of the "Miasma" supply-chain campaign, a JavaScript-ecosystem activity cluster that poisoned more than 20 npm packages and reached into GitHub Actions in pursuit of developer and continuous-integration secrets. According to Socket, the supply-chain intelligence firm that tracked the activity, the malicious versions were published in a tight, largely automated burst on June 24, 2026, affecting packages tied to the LeoPlatform and RStreams data-pipeline ecosystems and a related Go-module compromise. The end goal, the researchers said, is to harvest credentials and weaponize them to spread further across registries, repositories, and trusted developer workflows.

The disclosure is less a new threat than the latest pulse of one The CyberSignal has been tracking for weeks. Socket links this wave to the same operational cluster behind the related Mini Shai-Hulud and Hades families and the earlier Red Hat npm Miasma incident, which means the defensive playbook is by now well established: this is a supply-chain problem, and the work for affected organizations is developer-secret rotation and a GitHub Actions audit rather than a single patch.

What the Researchers Disclosed

In its analysis, Socket described a coordinated burst of malicious npm publishing on June 24, 2026, in which more than 20 packages received trojanized versions within a short window. The affected releases were tied to the LeoPlatform and RStreams ecosystems — libraries used in data-pipeline and cloud-integration workflows — and the researchers noted a related compromise of a Go module as part of the same activity. The pattern of rapid, near-simultaneous publishing across multiple packages is consistent with an automated operation working through credentials it already controls.

The technical hallmark of this wave is its install-time execution method. Rather than relying on a conventional npm install script — the kind that modern scanning and registry controls increasingly flag — the malicious packages include a binding.gyp file. When npm encounters that file it automatically invokes node-gyp, a native build tool, and that behavior is what triggers the hidden payload. Researchers have characterized this binding.gyp approach as a more sophisticated evasion than earlier variants, because it routes code execution through a legitimate build step rather than an obvious lifecycle hook.

Socket placed the wave within a broader threat cluster, connecting it to the related Mini Shai-Hulud and Hades malware families and to the earlier Miasma activity that struck Red Hat npm packages. In the researchers' framing, these are not unrelated incidents but successive waves and variants drawn from a shared tooling lineage that has worked its way across the npm ecosystem and adjacent registries through 2026. That continuity matters for defenders, because it means the indicators, behaviors, and remediation steps documented in prior waves largely carry over.

Defender Posture for Organizations Using Affected Packages

For an organization that consumed any of the affected packages, the immediate question is exposure rather than attribution. The first step is to determine whether any build, developer workstation, or CI/CD runner installed a poisoned version during the relevant window — and because the malicious code executes at install time, a single dependency resolution that pulled a trojanized release is enough to assume the host's accessible secrets were exposed.

Practically, that means treating the installation event, not just active use of the library, as the trigger for response. Lockfiles and build logs are the most reliable starting point: they record exactly which versions resolved and when, and they let a team distinguish a host that merely had the package listed from one that actually pulled and ran a malicious version. Where the timeline overlaps the June 24 burst, the prudent assumption is that any credential reachable from that environment — cloud keys, registry tokens, repository access — should be considered compromised until rotated.

The scope of "affected" should be drawn generously. Because this wave self-propagates by stealing credentials and using them to publish further, the blast radius is not limited to the originally named packages; a compromised maintainer token can carry the activity into other projects. Defenders are better served by scoping response around the credentials and systems that touched any flagged package than by trying to enumerate a fixed, final list of malicious releases while the cluster is still active.

GitHub Actions Audit and Developer-Secret Rotation

The GitHub Actions dimension is what elevates this from a dependency-hygiene chore to a CI/CD incident. The malware does not simply run on developer laptops; according to the researchers it abuses GitHub Actions workflows and scrapes the memory of Actions runners, where build-time secrets are frequently exposed. Rather than exfiltrating to a traditional command-and-control server, the activity has been observed committing stolen data to GitHub repositories created through the victim's own account — a technique that blends in with normal developer traffic and complicates network-based detection.

The audit work therefore has two parts. The first is rotation: any secret that was available to an affected build or runner — cloud provider keys, npm publishing tokens, GitHub personal access tokens, and similar credentials — should be rotated on the assumption it was read. The second is workflow review: teams should examine their GitHub Actions configuration for unexpected workflow changes, newly created repositories or commits associated with build identities, and overly broad permissions or long-lived secrets that a single compromised runner could harvest in one pass.

This is also a moment to revisit structural CI/CD hardening rather than just clean up after one wave. Scoping Actions secrets narrowly, preferring short-lived OpenID Connect-based credentials over static tokens, restricting which workflows can access which secrets, and monitoring for anomalous repository creation under automation identities are the controls that blunt this entire class of activity. Because the cluster's whole strategy is to convert one stolen credential into the next compromise, reducing what any single runner or token can reach is the durable defense.

Relationship to Prior Miasma and Mastra/Sapphire Sleet Coverage

This wave is best understood as a continuation, not a new campaign. The CyberSignal previously covered the Miasma open-source worm toolkit published on GitHub, as well as the Miasma worm's reach into Microsoft and GitHub repositories. Socket's June 28 framing ties the latest npm burst to that same operational cluster and lineage, alongside the related Mini Shai-Hulud and Hades families — so readers tracking the earlier stories should treat this as the next pulse of a known threat rather than a separate event.

It also sits within a busy run of JavaScript-ecosystem supply-chain disclosures more broadly. The same period saw the Mastra npm compromise affecting 145 packages via a contributor-account takeover, and the Cordyceps CI/CD activity that reached roughly 300 GitHub repositories. Taken together, the picture is one of overlapping, registry-targeting clusters whose differences matter less to a defender than their shared method: steal a developer or maintainer credential, then use it to reach the next set of packages and runners.

The throughline across all of these is that the open-source supply chain is now a sustained operating environment for credential-harvesting activity rather than the site of occasional, isolated incidents. That reframing is the practical takeaway: the same rotation-and-audit response keeps coming up because the same fundamental technique keeps working, and organizations that build that response into routine practice are better positioned than those treating each disclosure as a one-off fire drill.

Open Questions

Several details remain in motion. The precise, final count of affected packages and versions is the kind of figure that tends to grow as researchers and registry operators continue triage, so the "20-plus" number should be read as a snapshot of an active situation rather than a closed tally. Likewise, the full downstream impact — how many organizations pulled an affected release before it was flagged — is difficult to bound while the cluster remains operational.

Questions of precise attribution and operator identity also stay open. Socket's reporting links the wave to a shared cluster and tooling lineage spanning Miasma, Mini Shai-Hulud, and Hades, but a single named operator is not something the disclosure asserts, and The CyberSignal does not infer one beyond what the researchers state. What is firmly established is the method and the goal: install-time execution via binding.gyp, GitHub Actions abuse, and the harvesting of developer and CI/CD secrets to fuel further spread.

That confirmed core is enough to act on. Organizations that consumed any affected package should rotate exposed developer and CI/CD secrets, audit their GitHub Actions workflows for anomalous changes and repository creation, and treat the disclosure as a prompt to harden their pipeline credentials generally. Given that this is the latest wave of a cluster that has repeatedly resurfaced, the durable posture is to assume more waves will come and to make the rotation-and-audit response standing practice rather than a reaction.

Sources