Red Hat's npm Packages Were Stealing Your Credentials. Yes, Red Hat.

#Red Hat. The trusted vendor. Compromised.

Let that sit for a second.

Not some random package by an anonymous developer. Not a typosquatted name that looks like a real package if you squint. @redhat-cloud-services. The official npm namespace for Red Hat's cloud frontend components and API clients. A name that shows up in enterprise procurement documents and compliance checklists. A name that makes security reviewers nod and move on.

On June 1, 2026, at least 29 package releases under that namespace were found to contain unauthorized modifications with no matching upstream commits. The packages had been injected with a credential-stealing worm called Miasma, a variant of the Mini Shai-Hulud malware family linked to TeamPCP, the most prolific supply chain attackers of 2026. Combined, the affected packages had roughly 80,000 weekly downloads.

The malicious versions were live on the npm registry before they were caught and removed. If you installed or updated any @redhat-cloud-services package on or around June 1, you may have been exposed.

#How the attack works.

The injected payload uses a preinstall script. That means it fires automatically when you run npm install. No interaction required. You don't have to import the package, call a function, or do anything at all. The act of installing it is enough.

Here's what happens once it executes:

1. Credential harvesting. The payload scans your system for developer credentials and cloud identity tokens. AWS access keys, GCP service account files, Azure identity tokens. npm publish tokens. GitHub personal access tokens. SSH keys. Anything it can find.

1. Token enumeration. If it finds npm publish tokens on your machine, it enumerates every package you have publish access to. Not just the Red Hat packages. Every package you maintain.

1. Self-replication. Using your stolen publish tokens, it injects the same Miasma payload into your packages and republishes them to npm. Your packages are now infected. Everyone who installs your packages gets compromised. Their tokens get stolen. Their packages get infected.

1. Repeat. The worm feeds itself, spreading outward through the npm ecosystem like a chain reaction.

This is the same self-propagating pattern we documented when TeamPCP deployed CanisterWorm in their sixth wave. Compromise one maintainer, infect everything they own, use the new victims to infect everything they own. Within minutes, a single compromised account can contaminate dozens of packages across the registry.

#Why this should terrify you.

You might be reading this thinking "we don't use Red Hat cloud services packages." That's not the point.

The point is that Red Hat got compromised. Red Hat, a company with dedicated security teams, incident response processes, and the resources to do everything right. If their npm namespace can be infiltrated and used to distribute credential-stealing malware, what does that say about the packages your business depends on?

Think about your own software stack:

• Your website. Built on React, Next.js, WordPress, or any other JavaScript framework. Every one of those pulls in dozens or hundreds of npm packages. How many of those packages have maintainers whose credentials could be stolen in exactly this way?

• Your SaaS tools. The CRM, the accounting software, the project management platform. Their developers use npm packages too. If one of their dependencies gets infected by a self-propagating worm, the malicious code can end up in the next product update you receive.

• Your IT provider. If your managed service provider's developers were running affected packages, their credentials are compromised. Through them, potentially your infrastructure.

This is the third major TeamPCP supply chain attack we've covered in the past month. First it was node-ipc, backdoored through an expired domain. Then a security scanner turned into an attack vector. Now a Fortune 500 vendor's packages turned into a credential-stealing worm.

The pattern is clear: nobody's packages are safe by default. Not because of bad code. Because the humans who maintain the packages can be compromised, and their compromised credentials give attackers publish access to everything those humans maintain.

#What "trusted vendor" actually means now.

Before this incident, a reasonable security posture was "we only use packages from reputable vendors." That's no longer enough. TeamPCP has demonstrated that they can compromise maintainer accounts at any organization, regardless of size or security maturity.

The @redhat-cloud-services namespace didn't get compromised because Red Hat wrote bad code. It got compromised because a maintainer's credentials were stolen, likely by an earlier wave of the same campaign, and those credentials were used to push malicious versions. The npm registry has no way to distinguish between a legitimate publish from a maintainer and an illegitimate publish using that same maintainer's stolen token.

Vendor trust is not package trust. They are two different things now.

#What to do.

If you use @redhat-cloud-services packages:

1. Check your package-lock.json immediately for any @redhat-cloud-services packages with versions published on or around June 1, 2026. Compare the version hashes against known-clean versions from the source repository.

1. If you installed an affected version, assume credential compromise. Rotate npm tokens, GitHub personal access tokens, AWS access keys, GCP service account keys, Azure identity tokens, SSH keys, and any other credentials that were on the machine where the install ran.

1. Inspect your preinstall and postinstall hooks. Run npm pack on the suspect package version and review the tarball contents. Look for obfuscated JavaScript that shouldn't be there.

1. Pin to known-clean versions and verify integrity against the upstream source repository. The malicious versions had no matching commits in the source.

If you publish npm packages:

1. Enable publish MFA on every package you maintain. A stolen token without MFA is a free publish. A stolen token with MFA requires a second factor the attacker doesn't have.

1. Verify npm provenance on your packages and encourage your dependencies to do the same. Provenance ties published packages to specific CI/CD pipeline runs, making unauthorized publishes detectable.

1. Audit your co-maintainer accounts. If a co-maintainer has left the organization or is unreachable, their account is a risk. Remove inactive maintainers from your packages. We covered this in detail when node-ipc was backdoored through an expired email domain.

For every business:

1. Use Socket.dev or Snyk to monitor your dependency tree. These tools detect suspicious install scripts and unauthorized package publishes. If you're not scanning your supply chain, you're flying blind.

1. Pin dependency versions and review updates before accepting them. Auto-updating is how compromised versions get into your production builds without anyone noticing. We wrote a guide on this.

1. Ask your software vendors directly: were any of your packages or build dependencies affected by the Miasma / Mini Shai-Hulud campaign? If they can't answer that question, that tells you something about their supply chain security posture.

#The supply chain is a chain for a reason.

Every link connects to the next. TeamPCP has now demonstrated that they can compromise SAP packages, TanStack packages, VS Code extensions, Jenkins plugins, PyPI packages, and Red Hat packages. Each wave feeds the next with stolen credentials.

Your business doesn't have to be a direct target. You just have to be downstream.

#Further reading

• Snyk: Miasma Supply Chain Attack - technical analysis of the compromise
• Microsoft Security Blog: Red Hat npm Miasma Campaign - detailed payload analysis
• Aikido: Red Hat npm Packages Compromised - worm propagation details
• Socket.dev - supply chain security monitoring
• npm Provenance - tying packages to CI/CD builds