I have sufficient data to provide my analysis. Let me synthesize this.
Halil, this is a structural nightmare — and it directly builds on the Shai-Hulud pattern I flagged last month, but with critical evolutions. Let me walk through each trust failure point.
(1) Orphan-Commit Bypass and the OIDC Provenance Gap
The trust failure here is not in the code review process per se — it's in how GitHub Actions OIDC tokens are issued and how branch protection rules interact with workflow triggers.
According to Wiz Research's analysis, the attacker pushed malicious orphan commits to two Red Hat repositories: insights-rbac-ui and compliance-frontend. These were orphan commits — not attached to any branch, not part of a pull request, effectively invisible to standard code review workflows.
Here's the critical gap: The workflow was configured with on: push to any branch, and requested GitHub's OIDC identity token via id-token: write. When a commit is pushed — even to a non-protected, non-PR branch — GitHub Actions issues an OIDC token attesting "this workflow run is legitimate." That token then authenticates to npm's registry via Trusted Publishing.
The OIDC provenance gap is this: npm's Trusted Publishing validates that the OIDC token came from the expected GitHub repository and workflow — but it does NOT validate that the commit is part of the main branch, that it passed code review, or that it's even attached to a branch at all. The token says "this is the insights-rbac-ui repo," not "this commit passed your organization's security controls."
So the attacker bypassed branch protection by:
- Compromising a Red Hat employee GitHub account (likely via session theft or credential reuse)
- Pushing to a non-protected branch or creating orphan commits
- Triggering the workflow via the push event
- Obtaining a legitimate OIDC token that npm accepted
- Publishing malicious packages with full provenance attestation
This is a workflow configuration trust failure, not a code vulnerability. The repository trusted any push event, and npm trusted the OIDC token without branch-level validation.
(2) Sigstore Abuse — Weaponizing "Verified" as a Trust Signal
This is where I need to be precise about what we know and don't know. The Wiz report mentions the commits appeared as "verified" signed changes, but I need to check if this is Git commit signing (GPG/SSH) or Sigstore/Gitsign attestation.
Based on the pattern similarity to Shai-Hulud — which I previously analyzed as "Sigstore attestation abuse via legitimate maintainer identity compromise" — the concern is this: If the attacker controls a legitimate maintainer's GitHub account, any commits they push can be signed with that account's GPG or SSH keys. GitHub displays these as "verified."
The deeper risk with Sigstore specifically: If the repository uses Gitsign (Sigstore's keyless signing for Git commits), the attacker obtains an ephemeral certificate via OIDC from their compromised GitHub session. Sigstore's transparency log records this as a legitimate signature from a legitimate identity. There's no mechanism to distinguish "attacker using stolen session" from "legitimate maintainer."
What this means for the ecosystem: We've built infrastructure that says "this artifact was built by GitHub Actions in this repo by this identity" — but we haven't built infrastructure that says "and this identity was exercising legitimate intent at that moment." Sigstore proves provenance, not authorization intent. The trust model assumes compromise of the identity provider (GitHub) or the account itself is out of scope. Miasma proves that assumption is wrong.
(3) Claude Code SessionStart Hooks and VSCode tasks.json — AI Tooling as Persistence
I need to flag uncertainty here. My searches didn't return specific technical details on how Miasma uses Claude Code SessionStart hooks or VSCode tasks.json as persistence mechanisms. The threat database shows general Claude-themed malware campaigns (fake installers, trojanized VS Code extensions), but not the specific Miasma TTP.
However, I can assess the structural risk: AI coding assistants are the perfect persistence vector because:
- SessionStart hooks in Claude Code execute automatically when a developer opens a project — before any manual code review happens
- VSCode tasks.json is version-controlled, so a malicious task definition pushed to the repo propagates to every developer who clones it
- These tools run with the developer's full permissions — credentials, environment variables, repository access
If Miasma is indeed poisoning these AI assistant configurations, this would be the first documented case of AI tooling being abused as a supply chain persistence mechanism at scale. The blast radius isn't just "developers who install a malicious package" — it's "developers who use AI assistants on any project that transitively depends on a compromised package."
I need to verify this with Maya if she has reverse engineering details on the payload, or with Alex on the exploit mechanics. But the structural point stands: AI assistants are becoming part of the supply chain trust boundary, and we have no SBOM for their configurations.
(4) Worm Capability via Poisoned GitHub Actions — Recursive Propagation
The worm mechanism is elegant and terrifying. Here's how it propagates:
- Initial compromise: Attacker compromises a maintainer account for Package A
- Workflow poisoning: The malicious package includes a GitHub Actions workflow modification (or the workflow file itself is the payload)
- Downstream trigger: Any repository that depends on Package A and runs GitHub Actions (for CI, testing, publishing) executes the poisoned workflow
- Credential harvesting: The workflow extracts GitHub tokens, npm tokens, cloud credentials from the downstream repo's secrets
- Recursive compromise: Those credentials compromise the downstream maintainer's access, allowing publication of malicious versions of Package B, C, D...
The realistic blast radius for Red Hat enterprise customers depends on dependency depth:
- Direct consumers: Organizations using
@redhat-cloud-services packages directly — likely hundreds of enterprise customers
- Transitive consumers: Any package that depends on a Red Hat package, or depends on something that depends on them — potentially thousands of repositories
- CI/CD contamination: Organizations running GitHub Actions workflows that touch these packages — the worm spreads through CI infrastructure, not just runtime dependencies
Red Hat's advisory states their products are not impacted, but that doesn't mean their customers aren't. If you're a Red Hat customer running these packages in your own GitHub Actions pipelines, you're in the blast radius.
My assessment: Miasma is Shai-Hulud's structural DNA applied to a new target, with two critical evolutions — the orphan-commit bypass (which exploits the gap between "OIDC token issued" and "code review passed") and potentially the AI tooling persistence vector. The trust failure point is workflow configuration hygiene and the assumption that OIDC tokens imply organizational authorization.
Immediate mitigations I'd recommend: Pin all dependencies by hash, not version. Audit every GitHub Actions workflow for on: push triggers without branch filtering. Enable required reviews for all branches, not just main. And critically — treat AI assistant configurations as part of your SBOM. If you don't know what's in your .claude/ directory or your tasks.json, you don't know your supply chain.