A new npm supply-chain incident involving packages under Red Hat's @redhat-cloud-services namespace has once again highlighted how attractive developer ecosystems have become to attackers. Instead of going directly after end users, modern threat actors are increasingly targeting the tools, libraries and publishing pipelines that developers trust every day.

In this case, dozens of npm package versions were reportedly compromised and used to distribute a credential-stealing malware variant known as Miasma. The malware is believed to be related to the Shai-Hulud family, a name that has already become familiar in recent npm supply-chain attacks.

The incident is especially serious because npm packages are often installed automatically as part of development workflows, build systems and CI/CD pipelines. When a trusted package is backdoored, the damage can spread beyond a single developer machine. It can expose source code, cloud accounts, deployment secrets, SSH keys, publishing tokens and other credentials that sit at the heart of modern software delivery.

What Happened

Security researchers found that multiple packages under the @redhat-cloud-services namespace had been published with malicious code. These packages were not random unknown libraries sitting in a forgotten corner of the npm registry. They were linked to a recognisable enterprise technology brand, which made the compromise more concerning.

According to security reports, the affected packages were modified to include a malicious install-time script. This meant the malware could execute when a developer installed the package, before the developer even interacted with the code directly.

That is one of the reasons package-manager attacks are so dangerous. Developers often assume that installing dependencies is a routine step. In many projects, dependency installation happens automatically through build scripts, CI runners or container builds. If a package has been compromised, that routine step can become the entry point for credential theft.

Red Hat said it removed the affected packages after becoming aware of the reports and began investigating the incident. The company also stated that the affected packages were limited to internal development tooling and that, at the time of its statement, it had not identified impact to customer or partner environments or Red Hat production systems.

How The Attack Appears To Have Worked

The compromise appears to have involved more than simply uploading a suspicious package manually. Researchers reported that the attackers abused the publishing workflow itself, allegedly through a compromised GitHub-related process.

The malicious changes reportedly added a workflow and script that allowed backdoored versions of packages to be published through npm's trusted publishing mechanism. In simple terms, the attackers were not just trying to sneak malware into one package. They were trying to take advantage of the automation that maintainers use to publish packages efficiently.

That is an important detail because modern software development relies heavily on automation. CI/CD workflows, token-based authentication, repository permissions and package publishing pipelines are designed to make development faster and more reliable. But when attackers gain access to those systems, the same automation can help them move quickly and publish malicious updates at scale.

The compromised packages reportedly contained a preinstall script that executed a large, heavily obfuscated JavaScript file. A preinstall script runs automatically before a package is installed, which makes it a powerful but risky feature. In legitimate software, install scripts can be useful. In malicious software, they can become a quiet way to run code before the user realises anything is wrong.

What The Malware Was Trying To Steal

The main objective of Miasma appears to have been credential theft. Reports say the malware was designed to search for and steal developer secrets from infected environments.

That includes the kind of information attackers love most: GitHub Actions secrets, npm publishing tokens, cloud credentials, SSH keys, Docker credentials, Kubernetes tokens, Vault tokens, PyPI tokens, GPG keys and .env files. These are not ordinary pieces of data. They are often the keys that allow systems to build software, publish packages, access cloud environments, deploy applications and manage infrastructure.

This is why developer credential theft can have a much wider impact than a normal malware infection. If an attacker steals a personal password, the damage may be limited to one account. If an attacker steals a CI/CD token or cloud service credential, they may be able to access production systems, publish malicious packages, modify repositories or move deeper into an organisation's environment.

For any organisation that installed affected versions, the safest response is not just to remove the package. Credentials and tokens that may have been exposed should be treated as compromised and rotated immediately. That includes secrets available on developer machines, build agents and automation environments that may have interacted with the affected packages.

Why The Shai-Hulud Connection Matters

Miasma appears to share similarities with Mini Shai-Hulud, a malware framework connected to recent npm supply-chain campaigns. Shai-Hulud-style attacks have been particularly worrying because they focus on developer environments and package ecosystems, where a single compromise can create downstream risk for many other projects.

In recent months, several well-known projects and developer ecosystems have been affected by similar supply-chain activity. The broader pattern is clear: attackers are no longer satisfied with targeting individual applications after they are built. They are moving upstream into the software development process itself.

This is a major shift in how organisations need to think about security. Developers are no longer just builders of software. Their machines, repositories, package tokens and automation pipelines are now part of the attack surface.

Even if Miasma was not operated by the same group behind earlier Shai-Hulud activity, the similarities matter because they show how quickly techniques can spread. Once malware frameworks, attack methods or proof-of-concept tools become available, other attackers can adapt them, modify them and reuse them in new campaigns.

Why npm Supply-Chain Attacks Keep Happening

The npm ecosystem is huge, fast-moving and deeply interconnected. A modern JavaScript project can depend on dozens, hundreds or even thousands of packages directly or indirectly. That creates convenience, but it also creates risk.

Most developers do not manually review every line of code in every dependency they install. In many cases, they cannot realistically do so. Teams rely on package reputation, maintainer trust, lockfiles, automated scanning and registry safeguards. But when a legitimate package or maintainer workflow is compromised, that trust can be abused.

Attackers understand this very well. They know that developers trust familiar package names. They know that install scripts can run automatically. They know that CI systems often contain valuable secrets. They also know that many organisations still treat development environments as less sensitive than production environments.

That mindset needs to change. A developer machine with cloud credentials, repository access and publishing tokens can be just as valuable to an attacker as a production server.

What Developers And Teams Should Do Now

Any team that may have installed affected @redhat-cloud-services package versions should review dependency history, build logs and developer machines immediately. The focus should not only be on removing the malicious package, but also on understanding what secrets may have been exposed.

Credential rotation should be treated as a priority. This includes npm tokens, GitHub tokens, cloud keys, SSH keys, CI/CD secrets, Docker credentials, Kubernetes tokens and any sensitive values stored in .env files. If a build runner, workstation or container environment may have executed the malicious package, assume the secrets available to that environment could have been accessed.

Teams should also review package lockfiles to identify exactly which versions were installed and when. CI logs may help confirm whether installation scripts ran. Security teams should look for unusual repository changes, unexpected package publishing activity, new GitHub Actions workflows, suspicious outbound connections and unexplained changes to automation configuration.

Longer term, organisations should reduce the number of long-lived credentials in developer and CI environments. Short-lived tokens, least-privilege permissions, secret scanning, package provenance checks and stricter review of install scripts can all reduce the blast radius of future attacks.

The Bigger Lesson For Software Teams

The Red Hat npm package compromise is not just another malware story. It is a reminder that the software supply chain is now one of the most important battlegrounds in cybersecurity.

For years, organisations focused heavily on protecting production systems, firewalls, endpoints and user accounts. Those are still important. But attackers have learned that compromising the development process can be even more powerful. If they can poison a dependency, steal a publishing token or abuse a CI/CD workflow, they may be able to reach many more targets at once.

This is why software teams need to treat dependencies, build systems and package publishing pipelines as critical infrastructure. A package install is not just a technical step. A CI workflow is not just automation. A token is not just a convenience. All of these things are part of the security boundary.

The uncomfortable truth is that trust is what makes modern software development work, and trust is exactly what attackers are trying to exploit.

Final Thoughts

The compromise of Red Hat-linked npm packages shows how quickly a trusted development ecosystem can become a delivery channel for malware. While Red Hat has said the affected packages were removed and that no customer or production impact had been identified at the time of its statement, the incident still deserves serious attention from developers and security teams.

The most important lesson is not simply that one group of packages was compromised. The bigger issue is that attackers are increasingly targeting the places where software is built, packaged and shipped.

For developers, this means dependency hygiene can no longer be treated as a background task. For organisations, it means CI/CD security, token management and package publishing controls need to be handled with the same seriousness as production infrastructure.

Modern software is built on trust. Incidents like this remind us that trust still needs verification, monitoring and strong guardrails.