Red Hat npm Packages Compromised in Supply-Chain Attack Spreading Credential-Stealing Worm

A critical supply-chain attack has compromised 32 official npm packages under the @redhat-cloud-services scope, injecting a credential-stealing worm that runs automatically during package installation. Due to the severity and self-propagating nature of the malware, immediate investigation and credential rotation are required for any environment that installed the affected versions. The attack, dubbed “Miasma: The Spreading Blight,” was carried out on June 1, 2026 after a Red Hat employee’s GitHub account was compromised. The attacker injected malicious GitHub Actions workflows into three RedHatInsights repositories (frontend-components, javascript-clients, platform-frontend-ai-toolkit). The injected workflows leveraged GitHub Actions OIDC tokens to publish backdoored package versions with valid SLSA provenance attestations, making them appear fully legitimate. The attack is attributed to TeamPCP or a copycat using their open-sourced Mini Shai-Hulud tooling.

Technical Overview

The malware operates via a preinstall lifecycle hook that executes a 4.2 MB obfuscated JavaScript payload during npm install, before any application code runs. The attack occurred in two waves: 10:53 to 10:53:33 UTC and 13:44 to 13:46:47 UTC. Each compromised package version contained a comprehensive credential sweep targeting GitHub Actions tokens, AWS access keys and session tokens, GCP application default credentials and service account keys, Azure service principal credentials and managed identity tokens, HashiCorp Vault tokens, Kubernetes service accounts and kubeconfig files, npm and PyPI publish tokens, SSH private keys, Docker registry credentials, GPG keys, and all .env files. The malware generates uniquely encrypted payloads per infection, making hash-based IOC detection difficult. The worm’s self-propagating nature means that stolen tokens can be used to compromise additional packages and repositories, creating a cascading supply-chain effect.

Affected Systems

The following 32 packages under the @redhat-cloud-services scope are affected, with compromised versions listed:

• chrome (2.3.1, 2.3.2, 2.3.4)
• compliance-client (4.0.3, 4.0.4, 4.0.6)
• config-manager-client (5.0.4, 5.0.5, 5.0.7)
• entitlements-client (4.0.11, 4.0.12, 4.0.14)
• eslint-config-redhat-cloud-services (3.2.1, 3.2.2, 3.2.4)
• frontend-components (7.7.2, 7.7.3, 7.7.5)
• frontend-components-advisor-components (3.8.2, 3.8.3, 3.8.5)
• frontend-components-config (6.11.3, 6.11.4, 6.11.6)
• frontend-components-config-utilities (4.11.2, 4.11.3, 4.11.5)
• frontend-components-notifications (6.9.2, 6.9.3, 6.9.5)
• frontend-components-remediations (4.9.2, 4.9.3, 4.9.5)
• frontend-components-testing (1.2.1, 1.2.2, 1.2.4)
• frontend-components-translations (4.4.1, 4.4.2, 4.4.4)
• frontend-components-utilities (7.4.1, 7.4.2, 7.4.4)
• hcc-feo-mcp (0.3.1, 0.3.2, 0.3.4)
• hcc-kessel-mcp (0.3.1, 0.3.2, 0.3.4)
• hcc-pf-mcp (0.6.1, 0.6.2, 0.6.4)
• host-inventory-client (5.0.3, 5.0.4, 5.0.6)
• insights-client (4.0.4, 4.0.5, 4.0.7)
• integrations-client (6.0.4, 6.0.5, 6.0.7)
• javascript-clients-shared (2.0.8, 2.0.9, 2.0.11)
• notifications-client (6.1.4, 6.1.5, 6.1.7)
• patch-client (4.0.4, 4.0.5, 4.0.7)
• quickstarts-client (4.0.11, 4.0.12, 4.0.14)
• rbac-client (9.0.3, 9.0.4, 9.0.6)
• remediations-client (4.0.4, 4.0.5, 4.0.7)
• rule-components (4.7.2, 4.7.3, 4.7.5)
• sources-client (3.0.10, 3.0.11, 3.0.13)
• topological-inventory-client (3.0.10, 3.0.11, 3.0.13)
• tsc-transform-imports (1.2.2, 1.2.3, 1.2.5)
• types (3.6.1, 3.6.2, 3.6.4)
• vulnerabilities-client (2.1.8, 2.1.9, 2.1.11)

These packages averaged approximately 80,000 weekly downloads combined. Red Hat has confirmed that no Red Hat products or enterprise software were built or shipped with compromised versions, as version pinning by their engineering teams prevented product contamination. The primary risk is to downstream open-source consumers and organizations using these packages directly in their frontend applications, CI/CD pipelines, and build systems.

Risk Impact

Organizations that installed any of the compromised versions should immediately audit their dependencies and treat all CI secrets, cloud credentials, SSH keys, npm tokens, and other secrets accessible to the infected environment as compromised. Rotate all affected credentials without delay. Remove the compromised packages or pin to known-good versions prior to the first compromised version for each package. Investigate developer workstations, CI/CD environments, and GitHub Actions workflows for signs of unauthorized activity. Review GitHub token generation logs and repository activity for suspicious branches or workflow executions. Implement dependency allowlisting and SBOM validation as preventive controls going forward.

At the time of writing, the malicious packages have been identified and flagged. The open-sourcing of the Mini Shai-Hulud tooling means additional copycat attacks using similar techniques are possible. The severity, ease of exploitation through normal package installation, and self-propagating nature make this incident extremely high risk for any organization with exposed build environments or developer workstations. Successful exploitation results in complete exfiltration of credentials across cloud providers, CI/CD systems, container registries, and developer machines, potentially leading to lateral movement across infrastructure, unauthorized access to production environments, and further supply-chain compromise.

How Orca Can Help

Orca’s SCA (Software Composition Analysis) scanning detects the presence of compromised @redhat-cloud-services packages in customer container images and code repositories. Orca customers can quickly identify any assets running the affected package versions across their cloud workloads. Orca’s supply chain security capabilities provide visibility into these compromised dependencies, while contextual risk assessment highlights which affected assets are internet-facing, running in production, or have access to sensitive data, helping security teams prioritize their incident response and credential rotation efforts.