Red Hat Confirms Supply Chain Compromise Of @redhat-cloud-services npm Packages

Red Hat has confirmed a supply chain compromise affecting multiple npm packages published under the @redhat-cloud-services namespace after attackers used a compromised GitHub account to push unauthorized changes into packages maintained in a Red Hat GitHub organization.

The company said in RHSB-2026-006 that the affected packages are frontend JavaScript libraries used in the Hybrid Cloud Console web interface at console.redhat.com. Red Hat engineering removed the compromised versions from npm after disclosure.

Red Hat said no Hybrid Cloud Console release was published during the compromise window. The company also said its publication process strips installation-time scripts before deployment to console.redhat.com, and that no customer action is required based on current findings.

What Red Hat Confirmed

Red Hat’s investigation indicates that a compromised GitHub account was used to inject malicious code into repositories in the RedHatInsights GitHub organization. The company is still reviewing build systems and dependencies to confirm whether any product builds included the compromised package versions.

The affected packages are not tied to Red Hat managed cloud services such as Azure Red Hat OpenShift, OpenShift Dedicated, Red Hat OpenShift Service on AWS, Red Hat Advanced Cluster Security Cloud Service, or Red Hat Ansible Automation Platform on Cloud.

That distinction matters for customers. Red Hat product users who only consumed the deployed Hybrid Cloud Console face a different risk profile than developers or CI systems that directly installed compromised packages from npm during the exposure window.

Area	Confirmed detail
Package namespace	@redhat-cloud-services
Disclosure date	June 1, 2026
Initial compromise path	Compromised GitHub account used to push unauthorized commits
Affected package type	Frontend JavaScript libraries for the Hybrid Cloud Console web interface
Customer guidance	No customer action required based on Red Hat’s current findings
Investigation status	Ongoing

Researchers Link The Attack To Miasma And Shai-Hulud

Security researchers have linked the malicious payload to a Shai-Hulud variant called Miasma. OX Security said the infostealer targeted GitHub tokens, npm tokens, AWS, GCP, Azure cloud credentials, and local environment data.

Wiz Research said the attack affected at least 32 package releases at first, with unauthorized changes that did not match their corresponding source repositories. The Wiz advisory said those packages averaged roughly 80,000 weekly downloads.

Microsoft Defender Security Research later described a wider view of the same campaign. The Microsoft analysis identified 32 maliciously modified packages across more than 90 versions under the @redhat-cloud-services npm scope.

How The Malicious Packages Ran

The attack abused npm installation behavior. Several compromised packages included a preinstall script that executed malicious JavaScript during npm install, before normal application code had a chance to run.

StepSecurity said the payload targeted GitHub Actions secrets, AWS, GCP, Azure, Kubernetes, HashiCorp Vault, npm tokens, and CircleCI tokens. The company also said the payload tried to evade detection and included behavior aimed at CI/CD environments.

This is why direct npm consumers should treat the incident seriously. If a developer machine or CI runner installed a compromised package version, any credentials available to that environment may have been exposed.

• Check dependency lockfiles for affected @redhat-cloud-services package versions.
• Review CI/CD logs for npm install activity during the exposure window.
• Rotate npm tokens, GitHub tokens, cloud keys, SSH keys, and CI/CD secrets where exposure is possible.
• Audit GitHub organizations for unexpected repositories, commits, or secret exposure.
• Pause automatic dependency upgrades until package integrity is confirmed.

GitHub Was Used As A Payload Channel

Researchers said the malware did more than steal secrets and upload them to GitHub. In a follow-up report, OX Security said the campaign used GitHub commits tagged with the string “firedalazer” as a live payload delivery mechanism.

That approach made the malware more resilient. If one GitHub account was blocked, another account could push new commits and continue the payload chain. The technique also made network-level blocking harder because GitHub is widely trusted and commonly allowed in developer environments.

OX also noted a small but important detection issue. One stage used the string “Miasma: The Spreading Blight,” while another used “Miasma : The Spreading Blight” with a space before the colon. Exact-match detections that only look for one string may miss the other.

Detection clue	Why it matters
Miasma: The Spreading Blight	Observed marker tied to one malware stage
Miasma : The Spreading Blight	Variant marker that may evade exact-string detection
firedalazer	Commit string linked to GitHub-based payload delivery
preinstall script	Runs during package installation before application code executes
Unexpected GitHub repositories	May indicate credential exfiltration or malware-created repositories

Why The CI/CD Pipeline Risk Is Serious

Supply chain compromises inside npm packages can be dangerous because package installation often happens in privileged environments. CI runners may have access to cloud keys, deployment tokens, package publishing credentials, Kubernetes secrets, and private source code.

StepSecurity reported that all affected packages it examined were published through GitHub Actions OIDC from the RedHatInsights/javascript-clients repository. That points to the importance of monitoring trusted publisher workflows, not just ordinary npm maintainer tokens.

Microsoft also said the compromise originated from the RedHatInsights/javascript-clients CI/CD pipeline, which allowed attackers to publish trojanized packages through the legitimate GitHub Actions OpenID Connect publishing workflow.

What Developers Should Check

Developers should search package-lock.json, yarn.lock, pnpm-lock.yaml, build logs, container build records, and CI artifacts for affected @redhat-cloud-services versions. Any direct or transitive install during the exposure window should trigger a deeper review.

Teams should also check whether npm lifecycle scripts were allowed in build environments. If the affected packages ran with normal npm behavior, the malicious preinstall logic may have executed automatically.

Microsoft recommends reviewing dependency trees, identifying systems that installed affected package versions, pinning known-good versions where possible, using npm install with ignore-scripts in safer workflows, and rotating exposed credentials.

• Find all affected packages in direct and transitive dependencies.
• Identify developer machines and CI runners that installed affected versions.
• Rotate credentials available to those environments.
• Rebuild affected runners from clean images.
• Audit organization and personal GitHub accounts for suspicious repositories.
• Review package provenance, npm publishing history, and GitHub Actions activity.

Red Hat Product Customers Face A Different Exposure

Red Hat’s current customer guidance remains limited because the company says no Hybrid Cloud Console release was published during the compromise window. It also says installation-time scripts are stripped before deployment to the production console.

In its security bulletin, Red Hat says it is still conducting build system and dependency tracking analysis, and will update the bulletin as new information emerges.

That means organizations should separate two questions. One question is whether they consume Red Hat’s deployed services. The other is whether their own developers or build systems installed affected npm packages directly from the registry.

New Waves Show The Investigation Is Still Moving

The incident continued to evolve after the first disclosure. Wiz said on June 4 that it had published an additional advisory covering a new wave of packages linked to the campaign, including a set that abused binding.gyp to execute malicious code during installation.

The Wiz research said this newer wave still aligned with Mini Shai-Hulud and Miasma activity, but used a modified description string. That shows why defenders should not rely only on the first list of indicators.

In its separate six-stage analysis, OX Security also warned that the campaign was using multiple stages and an adaptive GitHub-based delivery pattern. The practical takeaway is that defenders need behavior-based hunting alongside static indicators.

Why This Incident Matters

This compromise highlights how a single developer account or publishing workflow can create risk across the software supply chain. Even if production Red Hat services were protected, direct npm consumers may still have exposed secrets if they installed the affected versions.

The StepSecurity report and the Microsoft Defender research both point to the same operational lesson: npm install is not a harmless step when lifecycle scripts can execute before code review or runtime deployment.

The earlier OX Security report also shows how Shai-Hulud variants continue to evolve after public tooling and earlier campaigns gave attackers a reusable template. Organizations should expect copycat and follow-on supply chain attacks, not treat this as a one-off event.

FAQ