Miasma Strikes LeoPlatform: Bun Evades Node, Cloud Keys Fall

On June 24, 2026, attackers hijacked the npm maintainer account “czirker” to publish 23 poisoned LeoPlatform and RStreams packages in under three seconds, deploying a Miasma variant that uses the Bun runtime to evade Node security tooling. The payload harvests AWS, Azure, GCP, Kubernetes, Vault and GitHub credentials from developer machines and CI/CD runners, exfiltrating them through the victim’s own GitHub account — with zero CVE assigned.

What Happened in Three Seconds

On June 24, 2026, an attacker seized the npm maintainer account “czirker” — almost certainly through leaked credentials — and used its publishing token to push 23 poisoned packages across the LeoPlatform and RStreams ecosystems. Microsoft Threat Intelligence confirmed the entire burst was “a coordinated, fully automated operation completed in under three seconds,” ruling out any chance of human hands on the keyboard between publishes. All 20 LeoPlatform packages landed at 2026-06-24T23:04:55Z, according to StepSecurity’s forensic timeline, sharing a single payload compiled from the same Miasma toolkit that already swallowed 73 Microsoft GitHub repositories earlier in June. Together those packages pull roughly 13,600 downloads a week.

The “czirker” takeover is the through-line of this whole campaign: Miasma does not need a novel zero-day in npm. It needs one tired maintainer who reused a password or leaked a token in a previous commit. Once the token is in hand, the worm publishes, propagates, and steals cloud credentials before any human reviewer can react. Socket researchers note the same operator has now extended into the Go ecosystem, compromising the verana-labs/verana-blockchain module — meaning this is no longer a JavaScript-only problem.

Why Bun Evades Your Security Tools

Here is the tactic that should make every cloud security team uncomfortable. Earlier Miasma waves hooked their payload through the familiar package.json preinstall/postinstall scripts — the exact surface that static analysis, npm audit, and most software composition analysis (SCA) tools learned to flag. This version drops those hooks entirely. Instead it plants a “Phantom Gyp” binding.gyp file that executes native build logic at install time, invisible to any tool keyed on lifecycle scripts.

The second evasion layer is runtime substitution. The loader downloads and executes the Bun JavaScript runtime (v1.3.13) rather than running under Node.js. As The Register reports, the operators do this “in the hope of attracting less attention from security software” — most endpoint and CI tooling instruments Node, not Bun, so the stealer payload runs effectively unobserved. The payload itself is wrapped in a three-layer obfuscation chain — a ROT-N cipher, AES-128-GCM, and obfuscator.io packing — and ships a Russian-locale killswitch plus an explicit endpoint-detection check before it detonates. If your detection strategy assumed malicious npm code announces itself through postinstall and runs on Node, it is now two assumptions behind.

The Cloud Credentials Now at Risk

The prize is not the package. The prize is everything your CI/CD runner and developer workstation can reach. Microsoft and The Register document the stealer hunting for AWS, Azure, and Google Cloud credentials alongside GitHub personal access tokens, Kubernetes secrets, HashiCorp Vault credentials, 1Password data, and npm publishing tokens. Critically, it also scrapes GitHub Actions runner memory — the live environment variables injected into every job, which frequently contain short-lived cloud keys, OIDC tokens, and database passwords.

That last detail matters more than the rest for cloud teams. The blast radius is not one developer’s laptop. Any pipeline that consumed an affected version — directly or transitively — executed the stealer with the union of every secret that pipeline could touch. The malware even drops a workflow named “Run Copilot” to harvest CI/CD environment secrets from the runner, then commits the encrypted haul to a GitHub repository created through the victim’s own account, with the description “Alright Lets See If This Works.” At the time of writing, Socket counted 559 repositories matching that string.

GitHub Is Now the C2 Server

Traditional incident response playbooks are built around egress detection: block known command-and-control IPs, watch for beaconing, hunt unusual outbound connections. Miasma renders that model partly obsolete. Sonatype’s analysis shows the campaign commits stolen data through the victim’s authenticated GitHub token to a repo the attacker controls — exfiltration that looks identical to legitimate developer activity and sails past egress firewalls.

The relay infrastructure has evolved too. Earlier waves tagged their tokens with the string "IfYouInvalidateThisTokenItWillNukeTheComputerOfTheOwner" as a blackmail-flavored marker. The current artifact uses "RevokeAndItGoesKaboom", a dead-drop resolver linked to the same campaign’s compromise of the codfish/semantic-release-action GitHub Action. That Action was force-pushed with a malicious commit on June 24 at 15:39:06 UTC, redirecting version tags so any workflow pinned to those tags executed the attacker’s payload directly inside the runner — stealing GitHub OIDC tokens, harvesting personal access tokens, and encrypting the loot with AES-128-GCM. The takeaway is brutal: in 2026 your package manager, your CI runner, and your git host can all become the same exfiltration channel, and none of it generates a suspicious packet.

The Zero-CVE Problem That Bites

Notice what is missing from this story: a CVE. There is no advisory number to grep for, no CVSS to prioritize, no KEV entry to chase. Phoenix Security flags this explicitly — the malicious packages carry zero assigned CVEs, because the vulnerability is not a memory corruption or a logic flaw. It is trusted code, published by a trusted account, executing as designed. Your vulnerability scanner has nothing to match.

This is the structural blind spot that keeps biting. CVE-driven patching assumes the threat is a flaw in software you already trust. Miasma is trusted software turned hostile, and no CVSS score captures that. Security programs that rank-queue everything by KEV and CVSS will correctly show zero exposure to this campaign while cloud credentials walk out the door. Detection has to move upstream of the CVE — to provenance, maintainer-account integrity, install-time execution, and credential egress — or it will keep missing the incidents that actually cost you.

Detection: Finding This in Your Stack

If you run anything from the LeoPlatform or RStreams families, treat the affected machines and runners as compromised until proven otherwise. Start with dependency provenance, not vulnerability scanning. Grep your lockfiles, internal package mirrors, build caches, container images, and CI runner images for the malicious versions listed above and in Socket’s full package list. Because there is no CVE, the only reliable signal is exact-version matching against the known-bad set.

Next, hunt the behavioral fingerprints the campaign cannot avoid. Look for binding.gyp files that spawn shell or download logic, any install-time fetch of the Bun runtime (bun-v1.3.13), the "Run Copilot" workflow artifact, the "RevokeAndItGoesKaboom" string, and newly created repositories owned by your developers with generic descriptions like “Alright Lets See If This Works.” Check your GitHub Actions audit log for force-pushes to pinned action tags — especially codfish/semantic-release-action — between June 24 and now. Finally, scan runner job logs for unexpected OIDC token issuance and outbound git pushes from automated jobs.

Your Cloud Credential Rotation Plan

Rotation order is the part most teams get wrong, and it matters. Sonatype is blunt: remove the malicious packages and hunt for persistence first, then rotate. If you swap credentials while the stealer is still resident, you hand the attacker a fresh set of keys. The correct sequence is eradicate, verify clean, then rotate.

1. Eradicate — remove affected package versions from lockfiles, mirrors, caches, and base images; rebuild affected runners and workstations from known-good state.
2. Verify — confirm no binding.gyp, Bun runtime, or "Run Copilot" artifacts remain; re-scan before promoting any rebuild.
3. Rotate — revoke and reissue every AWS, Azure, and GCP key, GitHub PAT, npm token, Vault credential, and Kubernetes secret reachable from any affected runner or machine. Treat OIDC trust relationships as exposed too.
4. Harden — require npm publishing 2FA enforced (not opt-in), adopt StepSecurity-style runner hardening, pin Actions to commit SHAs rather than tags, and instrument Bun runtime execution the same way you instrument Node.

The deeper lesson is architectural. Miasma succeeds because it treats developer trust and CI/CD automation as the attack surface — and that surface is now self-propagating, cross-language, and CVE-invisible. The campaigns will keep coming roughly every three weeks until the default assumption in every pipeline is that trusted code can turn hostile at any moment. Build your detection and credential-isolation model around that assumption, or plan to rotate your cloud keys again next month.

References

• The Register — Miasma campaign poisons 20-plus npm packages, hunts for developer secrets (June 26, 2026)
• The Hacker News — Miasma Malware Targets npm Packages and GitHub Actions in Supply Chain Attack (June 26, 2026)
• StepSecurity — Mass npm Supply Chain Attack: 20 Leo Platform Packages Compromised (June 25, 2026)
• Sonatype — Miasma Returns: Leo Platform Compromise in npm (June 25, 2026)
• Phoenix Security — Miasma/Hades Variant Hits LeoPlatform (2026)