Miasma npm Supply-Chain Attack Shows Why Trusted Software Must Be Continuously Verified

A credential-stealing worm reached developer machines through a trusted vendor namespace — and that makes supply-chain security an execution-control problem

Date: June 1, 2026 Primary Source: The Hacker News (The Hacker News)

Miasma npm supply-chain attack targeting developer and CI/CD environments — White Cloud Security Default-Deny Zero-Trust Application Control blocks the unapproved preinstall payload from executing

Executive Summary

What: Attackers compromised seven @redhat-cloud-services npm packages with a credential-stealing worm, using an obfuscated preinstall hook that runs during package installation. (The Hacker News)
Who is affected: Developers, build systems, and CI/CD pipelines that installed affected package versions.
Severity: High — the payload targets GitHub Actions secrets, npm tokens, cloud credentials, Kubernetes and Vault material, SSH keys, and Git credentials, then attempts to propagate using what it steals. (The Hacker News)
Action required: Inventory and rotate exposed credentials, hunt for the documented persistence artifacts, and add a Default-Deny execution-control layer so unapproved code cannot run even when it arrives inside a trusted package.

Overview

Software supply-chain security cannot rest on vendor reputation, namespace ownership, or package familiarity. Miasma is a clean demonstration of why: the packages carried a well-known vendor's name, and that name is exactly what made them effective.

The Hacker News reported the campaign on June 1, 2026. Researchers describe it as effectively a "Mini Shai-Hulud" campaign — the same core tactics as the earlier Shai-Hulud attacks: install-time execution, credential harvesting, CI/CD targeting, encrypted exfiltration, and potential downstream propagation. (The Hacker News)

The lesson for defenders is the one we keep returning to: installation is not authorization. A package manager placing a file on disk is a delivery event. Whether that file is permitted to execute is a separate decision — and it is the decision organizations can actually control.

What Happened in the Miasma Attack?

The Compromised Packages

Seven packages in the @redhat-cloud-services npm namespace were affected: (The Hacker News)

vulnerabilities-client
tsc-transform-imports
topological-inventory-client
sources-client
rule-components
remediations-client
rbac-client

Execution at Install Time

The malicious versions carried an obfuscated preinstall hook, so the payload executed during npm install — before a developer reviewed anything, and often as part of an automated build. (The Hacker News)

What It Steals

Once running, the payload harvests GitHub Actions secrets, npm tokens, cloud credentials, Kubernetes and Vault material, SSH keys, Git credentials, and other sensitive files. (The Hacker News)

Persistence Through Developer Tools

This is the part worth studying, because it shows where attackers now expect to find leverage. Rather than dropping a conventional startup entry, the malware persists through the developer's own tooling: (The Hacker News)

A SessionStart hook injected into Anthropic Claude Code, via ~/.claude/settings.json
A VS Code tasks.json entry using "runOn": "folderOpen" — so the task fires simply by opening the project
Modifications to repository files including .github/workflows/codeql.yml and .github/setup.js

Each of these is a legitimate, documented configuration mechanism. None of them is malware in the traditional sense. They are ordinary developer conveniences turned into execution triggers.

Exfiltration and Propagation

Encrypted payloads were sent to an endpoint at api.anthropic[.]com:443/v1/api, with GitHub used as a fallback channel — the malware commits an encrypted result envelope through the GitHub API. (The Hacker News)

To be precise about what that means: this is the attacker blending exfiltration traffic in with the kind of outbound connections a modern developer workstation makes all day. It is a traffic-camouflage choice by the attacker. It does not indicate that the service being imitated was involved in or aware of the campaign.

For propagation, the malware enumerates writable repositories, modifies GitHub workflows, and signs artifacts through Sigstore — an attempt to poison the supply chain further downstream using the access it just stole. (The Hacker News)

On Attribution — What Is and Is Not Known

The attacker is currently unknown. We want to be careful here, because supply-chain reporting invites overreach.

What the reporting supports: evidence suggests that the compromise of a Red Hat employee's GitHub account may have been the initial source — described as "patient zero" — used to inject malicious orphan commits. Whiteintel reportedly detected a Red Hat GitHub credential and session cookie in infostealer logs on April 13 and May 15, 2026. (The Hacker News)

Attribution is further complicated by the fact that TeamPCP open-sourced the original Shai-Hulud tooling, which means the same tactics are now available to unrelated actors. (The Hacker News) Similar technique does not establish a similar author.

Why Developer Machines and CI/CD Pipelines Are High-Value Targets

Attackers moved toward build environments for straightforward reasons:

Developers and build servers hold secrets. Cloud credentials, signing keys, registry tokens, and database access frequently sit on the same machines that run untrusted package code.
CI/CD environments can publish. A compromised pipeline does not just leak — it can ship software, containers, and updates to everyone downstream.
Install scripts execute before anyone looks. A preinstall hook runs automatically, often inside an unattended job at 3 a.m.
Trusted ecosystems provide cover. A package sourced from a familiar vendor namespace passes the human sniff test that an unknown package would fail.
One compromise becomes many. Stolen credentials convert a single infected workstation into access across repositories, registries, and cloud accounts.

At White Cloud Security, we continue to track and report new hacking methods and tools — not just because of their immediate threat, but because patterns of reuse often expose the playbooks of these cybercriminal groups.

Why "Trusted Source" Is No Longer Enough

A trusted vendor, a trusted repository, a signed commit, or a familiar package name tells you something about provenance. It tells you nothing reliable about the specific bytes currently sitting on disk.

Miasma makes the gap concrete. The vendor was legitimate. The namespace was legitimate. The registry was legitimate. The package name was one that a developer had installed before without incident. And the file that executed was still malicious.

Provenance is a claim about history. Execution control is a decision about the present. The file itself must be verified before it is allowed to run.

The Problem With Detection-Only Security

Detection-based tooling has to answer a hard question correctly and quickly: is this malicious?

To answer it, something must inspect, classify, score, or interpret the payload. That works well against known threats and considerably less well against a freshly obfuscated install hook inside a package that reputation systems rate as trustworthy.

There is also a timing problem. By the time a preinstall payload has been observed doing something suspicious, it has already run — and in this campaign, running once is enough to harvest tokens and write persistence into three separate configuration files.

Prevention asks an easier question: is this approved to execute? That question has a definite answer that does not depend on recognizing the threat.

How Default-Deny Changes the Outcome

With Default-Deny application control in place:

Unknown binaries do not run simply because they came from a familiar folder or vendor. Origin is not authorization.
Modified or newly introduced executables must be approved before execution. A package update that changes a file changes its identity.
Developer tools, build scripts, installers, and package managers can be controlled. These are executables and interpreters like any other, and they can be governed by policy.
Blast radius shrinks. A compromised developer workstation or build server has fewer paths available to it.
The security model shifts from "detect after execution" to "prevent unauthorized execution."

To be clear about scope, because this matters more than a strong claim would:

Default-Deny application control is a critical layer that can prevent unauthorized executables and tools from running, reduce attack paths, and give organizations stronger control over what is allowed to execute on endpoints and servers.

It is not a claim that any single control prevents every npm script, every credential-theft event, or every CI/CD compromise. Credential rotation, registry hygiene, workflow review, and least-privilege secrets management all remain necessary.

How White Cloud Security Trust Lockdown Helps

White Cloud Security (WCS) Trust Lockdown™ enforces Default-Deny Zero-Trust Application Control: only explicitly approved software executes, and unknown software is denied by default.

Critically, that decision does not rely on behavioral analysis or heuristics — there is no guess to get wrong, and nothing in the file influences the verdict.

Cyber-Metric Handprint Technology

Instead, White Cloud Security identifies files using its patented Cyber-Metric Handprint Technology, built from six attributes of the file itself:

Attribute	Role
SHA-1	Cryptographic hash
SHA-256	Cryptographic hash
SHA-512	Cryptographic hash
MD5	Cryptographic hash
CRC32	Checksum
File length	Size in bytes

Together these form a deterministic identity for a specific file. Change one byte of a package's payload and the handprint no longer matches an approved entry — regardless of whether the filename, the version number, the publisher, or the namespace stayed the same.

Identity Plus Enforcement

That identity model combines with Default-Deny enforcement to produce the behavior that matters in a supply-chain incident:

Attacker technique in Miasma	Why it defeats other controls	Default-Deny outcome
Malicious code inside a trusted namespace	Reputation and vendor checks pass	Unapproved file is Denied on identity, not reputation
Obfuscated `preinstall` hook	No signature to match yet	Unapproved interpreter or script invocation is Denied by policy
Modified package version	Name and publisher unchanged	Changed bytes produce a different handprint — Denied
Persistence via `tasks.json` / session hooks	Legitimate configuration mechanisms	The payload those hooks try to launch must still be approved

Trust can also be based on administrator-approved code-signing certificates in Trust Profiles, which lets organizations approve a publisher's legitimately signed software without hand-approving every file.

White Cloud Security does not need to identify the malware to stop unauthorized code from executing. It needs to know what the organization approved.

Practical Steps Organizations Should Take Now

If your teams use npm — and particularly if they consume @redhat-cloud-services packages:

Identify whether affected npm packages or versions were installed. Check lockfiles, build caches, and CI job history, not just current package.json files.
Isolate potentially affected developer workstations and build systems before investigating them.
Rotate exposed credentials — tokens, SSH keys, cloud credentials, and npm/GitHub tokens. Assume anything reachable from an affected machine is exposed.
Review GitHub workflows, npm publishing activity, CI/CD logs, container builds, and release artifacts for unexpected changes or publishes.
Hunt for the documented persistence artifacts: .vscode/tasks.json, ~/.claude/settings.json, .github/workflows/codeql.yml, and .github/setup.js. (The Hacker News)
Review which developer tools and package managers are allowed to execute on endpoints and build servers, and whether that list reflects a deliberate decision.
Adopt Default-Deny application control for developer endpoints, build servers, and production systems.

Step 5 deserves a note: those files are normal in most repositories. You are looking for unexpected entries within them, not for the files themselves.

Key Takeaways

Trusted namespace does not mean trusted bytes. Miasma shipped malicious code under a legitimate vendor's npm scope.
Install-time execution is the pivot point. An obfuscated preinstall hook runs before review, often unattended.
Persistence has moved into developer tooling — editor tasks, AI assistant session hooks, and repository workflow files.
Stolen credentials turn one compromise into many through writable repositories and publishing pipelines.
Attribution remains open. Evidence points to a compromised Red Hat employee GitHub account as the likely initial source; the actor is unknown, and shared tooling complicates the picture. (The Hacker News)
Handprint identity denies changed files that keep the same name, version, and publisher.
Default-Deny is one critical layer, not a complete answer — pair it with credential rotation and pipeline hygiene.

Conclusion

The Miasma attack shows that the software supply chain is now one of the most attractive paths into modern organizations. When attackers can abuse trusted packages, developer tools, and CI/CD workflows, organizations need more than detection. They need control.

White Cloud Security Trust Lockdown helps organizations enforce a Zero-Trust Application Security model by allowing only explicitly trusted software to run — and blocking everything else by default.

Eliminate threats before they start.

References

Analyses of this campaign were reported from Socket, Aikido Security, JFrog, Microsoft, OX Security, ReversingLabs, SafeDep, StepSecurity, and Wiz. (The Hacker News)