A new wave of malicious npm activity has been reported involving multiple packages in the legitimate @redhat-cloud-services namespace.

Public analysis from security researchers indicates that affected package versions contained install-time malware executed through npm lifecycle scripts, exposing developer machines and CI/CD environments to credential theft, persistence, and possible downstream package propagation.

Attackers included GitHub dead-drop repositories in the secondary payload containing the phrase "Miasma: The Spreading Blight." Sonatype is referencing Miasma in that context, as a campaign marker observed in reported payload behavior, not as independent attribution to a specific threat actor.

Some industry researchers connected this activity to TeamPCP and the broader Shai-Hulud malware campaigns. However, definitive attribution remains unclear.

The activity appears to use credential-theft techniques similar to those seen in recent npm supply chain campaigns, which may also reflect copycat behavior as attackers adopt methods that have already proven effective.

Compromised Packages in a Trusted Namespace

Several npm packages under the @redhat-cloud-services scope were compromised and published with embedded malicious code.

These were not typosquatted or lookalike packages, but rather legitimate packages in a trusted namespace, which makes the incident especially relevant for organizations that rely on package reputation or historical usage as indicators of safety.

Affected packages include, but are not limited to:

• @redhat-cloud-services/types

• @redhat-cloud-services/frontend-components

• @redhat-cloud-services/rbac-client

• @redhat-cloud-services/javascript-clients-shared

• @redhat-cloud-services/host-inventory-client

How the 'Miasma' Campaign Behaves

Sonatype Research observed that the affected Red Hat packages execute a heavily obfuscated script upon installation which attempts to download and run a second-stage payload from the author's server. Because this behavior is triggered during package installation, the payload can execute before application code imports the package or developers have a normal reason to inspect runtime behavior.

The second-stage payload appears to act as a Bun downloader with several malicious objectives:

• It can gather and exfiltrate environment variables, AWS credentials, and developer secrets.

• It also attempts to replicate by using discovered npm tokens to republish modified versions of packages the token can access, including use of npm's bypass_2fa parameter to bypass two-factor authentication protections.

• In addition, the payload can modify Claude Code and VS Code settings to inject malicious code that runs at the beginning of each session.

Simply removing the package may not be enough. If an affected version was installed, the host should be considered potentially compromised, and teams should investigate whether the second-stage payload downloaded additional malicious software or established persistence.

Why The Red Hat Compromise Matters

The Red Hat compromise and subsequent npm supply chain attack reinforces a notable pattern: attackers are increasingly targeting trusted packages, maintainers, automation tokens, and publishing workflows.

A package can appear safe because, increasingly often, a malicious package was safe yesterday. It may have a legitimate namespace, real maintainers, meaningful download history, and valid package metadata.

But if an attacker compromises the publishing path, a newly released version can become malicious while retaining the trust signals developers and automated pipelines already accept.

This should be treated as more than a dependency cleanup issue. For organizations that installed affected versions, it may be a credential exposure and CI/CD security incident.

What to Do if You Installed Malicious Versions

Organizations that may have downloaded affected @redhat-cloud-services package versions should begin by identifying exposure across source repositories, lockfiles, CI/CD logs, package caches, developer machines, and container images.

Recommended first steps include:

1. Search package.json, lockfiles, SBOMs, package caches, and build images for affected @redhat-cloud-services packages and versions.

2. Review CI/CD logs to determine if affected packages were installed with lifecycle scripts enabled.

3. Identify developer workstations or runners where npm install, npm ci, or equivalent commands may have executed the malicious versions.

4. Treat exposed environments as potentially compromised, especially if credentials were available during installation.

5. Isolate affected systems before rotating credentials where compromise is suspected.

6. Review GitHub, npm, cloud, and CI/CD audit logs for unexpected token use, repository changes, workflow edits, or package publishes.

7. Rotate exposed credentials from a clean environment after containment.

8. Rebuild CI runners, containers, or developer systems where compromise cannot be ruled out.

9. Assume the blast radius extends beyond the originally affected project and investigate other accessible projects and repositories for signs of compromise or propagation.

Teams should also look for suspicious install-time behavior, including unexpected preinstall scripts, unusually large or obfuscated JavaScript files, Bun execution during npm installation, unexpected outbound traffic during dependency installation, and suspicious changes to GitHub workflows or developer tool configuration files.

What Sonatype Customers Should Do

Sonatype customers should use their existing software composition analysis, repository management, and policy controls to identify and manage exposure to the affected package versions.

Recommended actions include:

• Search for affected @redhat-cloud-services packages and versions across applications, builds, repositories, and SBOMs.

• Review policy violations and malicious package intelligence as Sonatype data is updated.

• Block or quarantine confirmed malicious versions.

• Review dependency update automation to ensure compromised versions are not introduced through automated pull requests.

• Use repository controls to reduce direct dependency retrieval from the public npm registry where appropriate.

• Coordinate with security, DevOps, and application teams to determine whether any CI/CD credentials or developer machines were exposed.

• Expand the investigation to your other repositories for signs of propagation, including unexpected commits, workflow changes, or package releases.

• Leverage Sonatype Guide to help developers and AI coding assistants evaluate component health, security, and version risk before introducing or updating dependencies.

Trust Should Be Continuously Re-Evaluated

The reported @redhat-cloud-services compromise, with the descriptor "Miasma: The Spreading Blight," is another reminder that modern open source attacks are not limited to obscure packages or obvious social engineering.

For security teams, open source governance must move beyond static allowlists and one-time dependency approval. The question is not only if a package was safe when it was first adopted, but whether each new version, install-time behavior, and build environment interaction remains safe now.

Defending against this class of attack requires treating every new package version as a new risk decision, even when the package itself is familiar.