A sophisticated supply chain attack compromised several trusted Red Hat npm packages, allowing malware to steal developer credentials, infect CI/CD environments, and spread automatically across software projects.

Malicious code found in Red Hat, a major software supply chain security incident has raised concerns across the developer community. Researchers discovered that several legitimate npm packages under the trusted Red Hat namespace had been compromised and used to distribute malware.

Security firm StepSecurity reported that multiple packages within the @redhat-cloud-services npm scope contained malicious code that automatically executed during installation. The attack required no user interaction and ran before application code was loaded, making it particularly dangerous for developers and organizations.

A trusted source became the attack path

Unlike many supply chain attacks that rely on fake or lookalike packages, this campaign targeted legal and widely trusted packages. Researchers believe the attackers compromised the publishing pipeline connected to the RedHatInsights/javascript-clients repository.

Among the affected packages were:

  • @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

The malware was hidden inside a massive 4.2 MB installation script that was heavily obfuscated across multiple layers, making detection difficult.

Could your development environment still be infected

According to researchers, uninstalling the affected packages may not fully solve the problem.

The malware downloads a second-stage payload that can:

  • Exfiltrate credentials and environment variables.

  • Modify developer tools such as Claude Code and VS Code.

  • Inject malicious code that executes at the start of future sessions.

  • Establish persistence for continued access.

As a result, any machine that installed the affected versions should be treated as potentially compromised.

Researchers observed references to GitHub repositories containing the phrase "Miasma: The Spreading Blight." The term is being used as a campaign identifier rather than confirmed attribution to a specific threat actor. Some security experts have linked similarities in behavior to the broader Shai-Hulud and TeamPCP malware campaigns. However, investigators emphasize that definitive attribution remains uncertain.

Why this incident matters beyond red hat

The attack highlights a growing trend in cybersecurity: attackers are increasingly targeting trusted software supply chains rather than end users directly.

For years, organizations have relied on factors such as package popularity, reputation, and long download histories as signs of safety. This incident demonstrates that those indicators can quickly become unreliable if attackers gain access to publishing systems or automation workflows.

Security experts warn that every new package version should now be evaluated as a fresh security decision, regardless of how trusted the package may have been previously.

Recommended immediate actions

Organizations that may have installed affected versions should:

  • Search repositories, lockfiles, package caches, and SBOMs for affected packages.

  • Review CI/CD logs for installation activity.

  • Identify developer systems and build runners that executed the packages.

  • Isolate potentially compromised environments.

  • Rotate exposed credentials from clean systems.

  • Audit GitHub, npm, cloud, and CI/CD accounts for suspicious activity.

  • Rebuild systems where compromise cannot be ruled out.

  • Investigate other repositories for signs of malware propagation.

Looking ahead

As Business Fortune observes, the Red Hat npm compromise serves as another reminder that software supply chain attacks are becoming more sophisticated, automated, and difficult to detect. As attackers increasingly target trusted repositories and CI/CD pipelines, organizations will need continuous monitoring, stronger credential protection, and ongoing validation of every dependency update. In the future, trust alone will no longer be enough; every software release will need to earn that trust again.