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 published by Socket, the supply-chain security firm 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. As Help Net Security reported, 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. As The Hacker News noted, these are framed not as unrelated incidents but as 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.

The CyberSignal Analysis

The reported facts above are Socket's; what follows is The CyberSignal's editorial reading of what defenders should take from them. None of the judgments below are new reported facts.

Signal 01 — A Recurring Family Is a Standing Threat, Not an Event

The most useful reframing here is that Miasma is not an incident to be closed but a cluster to be tracked. Each disclosure — the worm toolkit, the reach into Microsoft and GitHub repositories, the Red Hat npm activity, and now this npm burst — has arrived as another pulse of the same lineage rather than a fresh, unrelated problem. Our reading is that organizations still treating each announcement as a discrete fire drill are structurally behind, because the tooling, the goal, and the remediation have stayed constant across every wave.

That has a practical consequence for how response is resourced. A one-off breach justifies a one-off scramble; a recurring family justifies standing instrumentation. The teams that fare best against Miasma are the ones that have made dependency-provenance checks, credential rotation, and workflow auditing routine operating practice — so that the next wave is met with an existing process rather than an improvised one.

Signal 02 — GitHub Actions Runner Memory Is the Control Gap

The detail we would put at the center of any post-disclosure review is that this activity reaches into GitHub Actions runners and scrapes their memory, where build-time secrets are routinely present in cleartext. That is the gap that turns a poisoned dependency into a CI/CD compromise: the runner is a trusted execution context that legitimately holds high-value credentials, and a payload running at install time inside that context can read them in a single pass. Committing the results to attacker-influenced repositories through the victim's own account, rather than to an external server, further blunts network-based detection.

Our assessment is that the durable fix is architectural rather than reactive. Narrowly scoped, short-lived credentials — OpenID Connect-based tokens over static secrets — mean that even a runner read to completion yields far less than a long-lived key. Restricting which workflows can reach which secrets, and monitoring for anomalous repository creation under automation identities, shrinks what any single compromised runner can convert into the next compromise.

Signal 03 — Developer-Secret Rotation Is the Correct Reflex

When a consumed package turns out to be part of a wave like this, the instinct to wait for a definitive list of what was stolen is the wrong one. Because the code executes at install time and the whole strategy is to harvest credentials for further spread, the defensible default is to assume every secret reachable from an affected build or runner was read — and to rotate on that assumption rather than on proof. Rotation is cheap relative to the cost of leaving a live, exfiltrated credential in place while triage continues.

The scope of that rotation should be drawn generously: cloud provider keys, npm publishing tokens, GitHub personal access tokens, and any other credential an affected environment could touch. Treating the installation event — not active use of the library — as the trigger is what makes this reflex effective. For a cluster whose entire economy is converting one stolen credential into the next, fast and broad rotation is the single response that most directly breaks the chain.

Sources