On 1 June 2026 Wiz Research found at least 32 malicious releases under the @redhat-cloud-services npm scope. The packages average about 80,000 weekly downloads combined. The root cause was a compromised Red Hat employee GitHub account that pushed orphan commits to several RedHatInsights repositories, skipping code review entirely.
Wiz calls the payload Miasma. It is derived from the open-sourced Mini Shai-Hulud malware. Wiz treats the overlap with TeamPCP as shared tradecraft, not proof of attribution, and notes a copycat cannot be ruled out.
What's affected
Wiz lists 32 packages, mostly three malicious versions each. A sample:
| Package | Malicious versions |
|---|---|
| @redhat-cloud-services/frontend-components | 7.7.2, 7.7.3, 7.7.5 |
| @redhat-cloud-services/rbac-client | 9.0.3, 9.0.4, 9.0.6 |
| @redhat-cloud-services/insights-client | 4.0.4, 4.0.5, 4.0.7 |
| @redhat-cloud-services/hcc-pf-mcp | 0.6.1, 0.6.2, 0.6.4 |
| @redhat-cloud-services/chrome | 2.3.1 |
| @redhat-cloud-services/types | 3.6.1, 3.6.2, 3.6.4 |
Most malicious versions were revoked within hours, but two remained at the time Wiz wrote. A second wave on 4 June (advisory wiz-adv-2026-096) used binding.gyp to execute at install, the same trick described in the Snyk node-gyp analysis. The releases added a preinstall script that ran an obfuscated index.js. Each infection got a uniquely encrypted payload, so file hashes only match one version.
How it happened
The attacker pushed commits to branches named oidc- plus a random suffix in the frontend-components, javascript-clients and platform-frontend-ai-toolkit repositories, in two waves at 10:53 and 13:44 UTC. Each commit added a workflow named release, triggered on a push to any branch, with id-token: write. The workflow requested an OIDC token and ran a Bun script with a list of target packages in an environment variable.
Because the publish came from a real workflow run in the real repository, the malicious packages carried valid SLSA provenance attestations. The attestation was truthful about where the package was built. It said nothing about whether the workflow should exist.
How to check if you're exposed
npm ls --all 2>/dev/null | grep '@redhat-cloud-services'
grep -n '@redhat-cloud-services' package-lock.json | head -50
Compare any hit against the version table in the Wiz post. Then search GitHub for the description "Miasma: The Spreading Blight" on repositories created under your accounts, and check your audit log for workflow runs you did not start.
What to do now
- Remove or pin away from the listed versions, then reinstall from a clean checkout.
- Treat any machine or CI runner that installed them as compromised. Assume GitHub tokens, SSH keys, cloud credentials and CI secrets are exposed. Wiz notes this variant adds collectors for GCP and Azure identities.
- Review GitHub activity for unauthorized repositories, newly created tokens and suspicious workflow runs.
- Rotate credentials only after the host is clean.
How this could have been avoided
- Protect every branch pattern that can publish. The new workflow ran on a push to any branch. Restrict publishing to a protected release branch or tag, and bind the OIDC trust policy to that ref and to a deployment environment.
- Require approval for workflow files. Code owners on
.github/workflows/and rulesets blocking direct pushes would have forced a reviewer to see a newreleaseworkflow. - Alert on orphan commits and new branches that touch workflows. An
oidc-branch with no shared history is easy to flag. - Phishing-resistant MFA and short sessions for employee accounts that can write to release repositories.
- Do not treat provenance as a verdict. Pair it with a check that the workflow path and ref match what the maintainers expect.
Why it matters
Trusted publishing removed long-lived tokens, and attackers responded by borrowing the pipeline itself. If someone can add a workflow to a repository that holds a publish trust, the registry will gladly accept their package.
Provenance proves where, not why. Policies need to name the exact workflow and branch that may publish.
Try it yourself
Open one of your own publishing repositories and check three things: which workflow files can request id-token: write, which branches trigger them, and who can push to those branches without review.
Click through it at your own pace, or open it full screen.
Quick check
Why did the malicious packages have valid provenance?
They were published by a real workflow run in the real repository, using a workflow file the attacker had added through a compromised employee account.
Which control would most directly have stopped the publish?
Binding the OIDC trust to a protected release ref and environment, so a workflow on an arbitrary branch cannot obtain a publish token.