A supply chain attack on npm packages belonging to Red Hat’s @redhat-cloud-services namespace was disclosed on June 1, 2026. The campaign, named Miasma by researchers at multiple security firms, compromised 32 official packages covering 96 published versions, with cumulative weekly downloads of approximately 117,000 at the time of discovery. The malicious payload is a variant of the Shai-Hulud credential-stealing worm, previously linked to the threat actor group TeamPCP.
How the attack was executed
The entry point was a compromised GitHub account belonging to a Red Hat employee. The attacker used that account to push malicious orphan commits directly to several Red Hat repositories, bypassing code review processes entirely. Because the affected repositories use GitHub Actions OIDC tokens for automated publishing workflows, the attacker was able to trigger the CI/CD pipeline and publish malicious versions of the packages to npm without needing direct write access to the npm registry.
This is the key architectural detail that makes Miasma significant beyond its credential-theft payload: the attacker did not compromise npm. They compromised the pipeline that publishes to npm. Any package that uses GitHub Actions with OIDC-based npm publishing, and whose CI workflow does not verify commit signatures or restrict which commits trigger a publish run, shares the same structural vulnerability.
What the payload collects
Once installed via npm, the Miasma payload performs a broad sweep across developer and infrastructure credentials. On the CI side, it targets GitHub Actions secrets including GITHUB_TOKEN and ACTIONS_RUNTIME_TOKEN – which can be used to read private repositories, modify Actions workflows, and chain further supply chain attacks downstream.
For cloud credentials, the worm collects AWS access keys and session tokens from the standard credentials file and environment variables, GCP application default credentials and service account key files, and Azure service principal credentials and managed identity tokens.
Beyond cloud providers, the sweep covers HashiCorp Vault tokens, Kubernetes service account tokens and kubeconfig files, npm and PyPI publish tokens, SSH private keys, Docker registry credentials, GPG keys, and any .env files in the working directory and common parent directories.
The breadth of this sweep means that a developer or CI runner that installs one of the compromised packages in a build environment where cloud credentials are present can expose the full cloud infrastructure of the organisation, not just the specific project being built.
Why this pattern keeps recurring
The @redhat-cloud-services namespace carries an inherent authority signal. Packages published under a major enterprise vendor’s official namespace are trusted by default in most corporate dependency policies and do not trigger the same manual review as packages from unknown publishers. Attackers have understood this since the Trapdoor campaign earlier this year and continue to target namespaces and organisations where the trust level is high enough to reduce friction for downstream installation.
Dependency pinning and lockfile verification address a related but different problem: they protect against accidental version drift, but they do not help if a developer or a CI system has pinned to a version that is itself now malicious. The only complete remediation is to rotate all credentials that were present in any build environment that installed one of the compromised package versions.
What DevOps and platform teams should do
Identify affected package versions immediately. The affected packages include widely used @redhat-cloud-services components for OpenShift, cloud security, and RBAC management. Check your dependency trees and lockfiles for any of the 32 affected packages at the compromised versions.
Rotate credentials as if they were already stolen. Any AWS access key, Azure service principal, GCP service account key, GitHub token, or Kubernetes service account token present as an environment variable or file in a build environment that installed a compromised version should be treated as compromised. Rotate first, investigate second.
Audit your GitHub Actions OIDC publishing workflows. If your organisation uses GitHub Actions with OIDC to publish packages, review whether your workflows enforce signature verification on commits before triggering a publish step, and whether branch or tag protection rules restrict which events can initiate a publish run.
Move to short-lived credentials in CI. Long-lived AWS access keys and service account keys stored as CI secrets are high-value targets precisely because they persist beyond the duration of any individual build. OIDC-based workload identity, where the CI system obtains a short-lived credential scoped to the current job, eliminates the class of stolen-secret attacks that Miasma depends on.
If you want help assessing your CI/CD pipeline for credential exposure, auditing your npm and package registry configurations, or implementing short-lived workload identity for GitHub Actions, GitLab CI, or other pipeline environments, contact Excello Digital. We help European engineering teams secure the pipelines that build and deploy their infrastructure.