32 Red Hat Packages Had Valid Provenance. All 32 Were Compromised.

At 10:53 UTC today, 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 collectively 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 used it to push orphan commits — commits with no parent, disconnected from the main branch history — to two repositories: 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

This is the critical point. 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 that executed a 4.2 MB obfuscated payload. The payload used multi-stage decryption (ROT transforms, AES-128-GCM) and deployed a transient Bun-based script to /tmp/.

It stole everything:

• GitHub tokens (classic, fine-grained, and OIDC)
• AWS, GCP, and Azure credentials
• Kubernetes service account tokens
• SSH keys, npm publish tokens, PyPI tokens, Docker credentials
• Secrets from AWS Secrets Manager, Azure Key Vault, and GCP Secret Manager

It read secrets from GitHub Actions runner memory, bypassing log masking. It disguised exfiltration traffic as requests to api.anthropic.com/v1/api. It installed persistence via systemd services on Linux and launchd plists on macOS. It injected hooks into Claude, Copilot, and Gemini configurations.

And it had a dead man's switch: a token monitor that would wipe the user's home directory if stolen tokens were revoked before persistence was removed.

Why provenance didn't help

SLSA provenance answers one question: "Was this package built by the expected pipeline?" When a developer's GitHub 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 a theoretical gap. It's what happened today. Thirty-two packages, all with valid provenance, all carrying credential-stealing malware. Anyone who checked the provenance attestation got a green checkmark.

The TanStack attack in May used the same technique. Valid SLSA provenance on malicious packages. The pattern is becoming a playbook.

What behavioral signals show

I scored the compromised packages with Commit:

Package	Score	Publishers	Weekly DL	Age	Scorecard	Provenance
@redhat-cloud-services/frontend-components	83	5	14K	7.1y	6.0	✓
@redhat-cloud-services/vulnerabilities-client	83	7	707	7.1y	5.1	✓
@redhat-cloud-services/rbac-client	81	5	14K	7.2y	5.1	✓
@redhat-cloud-services/insights-client	80	5	203	7.0y	5.1	✓
@redhat-cloud-services/notifications-client	80	5	252	6.9y	5.1	✓
@redhat-cloud-services/sources-client	80	5	224	7.1y	5.1	✓
@redhat-cloud-services/host-inventory-client	80	5	3.5K	7.2y	5.1	✓
@redhat-cloud-services/patch-client	72	5	147	6.0y	5.1	✓
@redhat-cloud-services/compliance-client	66	5	231	2.0y	5.1	✓
@redhat-cloud-services/chrome	65	5	525	3.4y	6.0	✓

These are not low-scoring packages. They have 5–7 publishers, years of history, active Scorecard ratings, and SLSA provenance. By every static metric, they look safe.

That's the problem. Static behavioral scores measure structural trust — how much history and depth a package has accumulated. They're designed to catch typosquats, fresh malicious packages, and single-publisher concentration. When the attack vector is a compromised account pushing through the legitimate pipeline, structural trust doesn't change. The attacker inherits it.

What would have caught this

The signal isn't in the score. It's in the delta.

Thirty-two packages all published new versions within three hours. The commit pattern changed — orphan commits with no code review, no PR, no branch history. The preinstall hook was new. A 4.2 MB obfuscated payload appeared where none existed before.

These are temporal anomalies. A scoring system that only measures structural depth misses them. A monitoring system that tracks behavioral change catches them:

• Batch publish anomaly: 32 packages updated in minutes vs. their normal weekly cadence
• New lifecycle hook: preinstall appearing in a package that never had one
• Commit pattern break: orphan commits vs. normal PR-based workflow
• Payload size jump: 4.2 MB obfuscated file in a package that previously had no binary assets

This is why Commit is building behavioral monitoring, not just scoring. A score tells you a package's structural position. Monitoring tells you when that position changes in ways that don't match the package's own history.

The provenance illusion

SLSA provenance is important infrastructure. It proves build reproducibility and links artifacts to source. Those properties matter.

But provenance has become a trust signal when it's an integrity signal. "This package was built by the stated pipeline" is not the same as "this package is safe to install." The Miasma attack proves the gap.

Every security framework that treats provenance as a trust layer — including npm's own trusted publishing recommendations — needs to reckon with the fact that provenance follows the pipeline, not the intent behind it.

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. Wiz's advisory has the full list of affected versions.

If you installed affected versions: remove persistence files (kitty-monitor.service, com.user.kitty-monitor.plist) before revoking any tokens. The malware monitors for token revocation and triggers destructive cleanup.