At 10:53 UTC on June 1, someone pushed malicious orphan commits to two Red Hat repositories on GitHub. By 13:46 UTC, 32 packages under the @redhat-cloud-services namespace had been republished with credential-stealing malware. The packages average 80,000 downloads per week.
Every malicious version carried valid SLSA provenance attestations.
Wiz Research published the full analysis. The attack is a derivative of the Mini Shai-Hulud malware family — the same lineage that hit TanStack in May.
What happened
A Red Hat employee's GitHub account was compromised. The attacker pushed orphan commits — commits with no parent, disconnected from the main branch history — to RedHatInsights/frontend-components and RedHatInsights/javascript-clients.
Those repositories had GitHub Actions workflows with id-token: write permissions. The attacker triggered the existing CI/CD pipeline, which:
- Built the packages from the malicious commits
- Published them to npm using the pipeline's own OIDC tokens
- Generated SLSA provenance attestations — signed, valid, verifiable
The provenance wasn't forged. The CI/CD pipeline genuinely built and published the packages. The attestations said "this package was built by Red Hat's CI/CD pipeline" and that was true. The pipeline just happened to be building malware.
The malware
Each compromised version embedded a preinstall hook executing a 4.2 MB obfuscated payload with multi-stage decryption (ROT transforms, AES-128-GCM). It stole:
- GitHub tokens (classic, fine-grained, OIDC)
- AWS, GCP, and Azure credentials
- Kubernetes service account tokens
- SSH keys, npm/PyPI tokens, Docker credentials
- Secrets from AWS Secrets Manager, Azure Key Vault, GCP Secret Manager
It disguised exfiltration traffic as requests to api.anthropic.com/v1/api. It installed persistence. It injected hooks into Claude, Copilot, and Gemini configurations. And it had a dead man's switch that wipes the user's home directory if stolen tokens are revoked before persistence is removed.
Why provenance didn't help
SLSA provenance answers: "Was this package built by the expected pipeline?" When a developer's credentials are stolen and the attacker triggers that same pipeline, the answer is yes. The provenance is valid. The package is malicious.
This isn't theoretical. Thirty-two packages, all with valid provenance, all carrying credential-stealing malware. Anyone who checked the provenance attestation got a green checkmark.
What behavioral signals show
I scored the compromised packages with Commit:
| Package | Score | Publishers | Weekly DL | Age | Scorecard | Provenance |
|---|---|---|---|---|---|---|
| frontend-components | 83 | 5 | 14K | 7.1y | 6.0 | ✓ |
| vulnerabilities-client | 83 | 7 | 707 | 7.1y | 5.1 | ✓ |
| rbac-client | 81 | 5 | 14K | 7.2y | 5.1 | ✓ |
| insights-client | 80 | 5 | 203 | 7.0y | 5.1 | ✓ |
| host-inventory-client | 80 | 5 | 3.5K | 7.2y | 5.1 | ✓ |
| patch-client | 72 | 5 | 147 | 6.0y | 5.1 | ✓ |
| compliance-client | 66 | 5 | 231 | 2.0y | 5.1 | ✓ |
| chrome | 65 | 5 | 525 | 3.4y | 6.0 | ✓ |
These are not low-scoring packages. Multiple publishers, years of history, Scorecard ratings, provenance. By every static metric, they look safe.
The signal isn't in the score. It's in the delta:
- Batch publish anomaly: 32 packages updated in minutes vs. normal weekly cadence
-
New lifecycle hook:
preinstallappearing where none existed before - Commit pattern break: orphan commits vs. normal PR-based workflow
- Payload size jump: 4.2 MB obfuscated file in packages with no binary assets
Check your project
npx proof-of-commitment
Scores every dependency in your lockfile. If you depend on any @redhat-cloud-services package, verify you're on a clean version.
If you installed affected versions: remove persistence files (kitty-monitor.service, com.user.kitty-monitor.plist) before revoking tokens. The malware monitors for revocation and triggers destructive cleanup.
Top comments (0)