"The attackers published 84 malicious versions across 42 TanStack packages that had valid provenance, valid Sigstore attestations, and legitimate GitHub Actions signatures."
TeamPCP and the Shai‑Hulud campaign
The supply‑chain operation, attributed to the TeamPCP threat group and tracked as the Shai‑Hulud campaign, first emerged in September. Since then it has iterated repeatedly, at times exposing hundreds of thousands of developer secrets in automatically generated GitHub repositories. The latest wave, which the reporting says occurred yesterday, began with compromised TanStack and Mistral AI packages and rapidly expanded to other widely used projects, including Guardrails AI, UiPath, OpenSearch, the Bitwarden CLI package, and official SAP packages.
How attackers abused GitHub Actions, OIDC, and SLSA
TanStack’s post‑mortem traces the intrusion to a chain of three failures: a risky pull_request‑target workflow, GitHub Actions cache poisoning, and theft of OpenID Connect (OIDC) tokens from runner memory. StepSecurity says the attacker used those stolen OIDC tokens to publish malicious package versions via legitimate CI/CD pipelines, producing "valid SLSA Build Level 3 attestations for malicious packages" and carrying "valid Sigstore attestations" tied to the genuine TanStack/router Release workflow. From a developer’s point of view, the packages appeared cryptographically authentic and showed no outward sign of compromise.
The malware: what it steals, how it exfiltrates, and how it persists
The injected payload is a credential‑stealer aimed squarely at developer and CI/CD secrets. StepSecurity and other vendors list the targets: GitHub Actions OIDC tokens and personal access tokens (PATs), Git credentials, npm publish tokens, AWS Secrets Manager and IAM credentials, ESC task credentials, Kubernetes service account tokens and cluster credentials, HashiCorp Vault tokens, SSH keys, Claude Code configs, VS Code tasks, and .env files. StepSecurity reports the payload reads GitHub Actions process memory to harvest credentials from more than 100 file paths tied to cloud providers, crypto tokens, and messaging apps.
For exfiltration the malware used the Session P2P network, making its traffic resemble encrypted messenger traffic and complicating detection, blocking, and takedown. The malicious code also attempts to retain access: it writes itself into Claude Code hooks and VS Code auto‑run tasks so that uninstalling the package does not remove the implant. The campaign’s propagation technique remains consistent with prior waves: stolen GitHub/npm credentials are used to enumerate packages tied to compromised maintainers, tarballs are modified to inject the payload, and malicious versions are republished.
Detection, vendor counts, and technical tricks
Multiple security vendors have tallied dozens to hundreds of artifacts. Endor Labs reports over 160 compromised packages on npm, Aikido recorded 373 malicious package‑version entries, and Socket tracked 416 compromised artifacts across npm, PyPI, and Composer. TanStack confirmed the attackers published 84 malicious versions across 42 packages within its namespace.
Researchers also identified a clever Git trick: attackers abused an orphaned commit pushed to a fork of the TanStack/router repository and referenced it via a malicious optional dependency. Because the orphaned commit was accessible through GitHub’s shared fork object storage, npm automatically fetched and executed attacker‑controlled code during install. SafeDep observes that although the trigger mechanisms differ between the compromised Mistral AI and TanStack packages, they drop the same credential‑stealing payload.
What technologists, maintainers, and enterprises should do
- Technologists and security teams: assume that any download of an affected package version may have exposed credentials. Recommended actions include checking for affected versions, checking developer machines for persistent implants, rotating all credentials (GitHub tokens, npm tokens, AWS credentials, Vault tokens, Kubernetes service accounts, CI/CD secrets), and auditing IDE directories for malicious files left by npm install such as router_runtime.js or setup.mjs.
- Open‑source maintainers: review CI/CD workflows for risky pull_request‑target patterns, harden GitHub Actions usage against cache poisoning, and protect runner memory from token theft. Maintain provenance hygiene, but recognize — as Snyk researchers note — that valid SLSA Build Level 3 attestations can be produced for malicious packages when CI credentials are stolen.
- Enterprises and procurement leaders: add behavioral analysis at install time in addition to provenance checks, apply signature‑based screening for known malicious packages, and consider enforcing lockfile‑only installs to prevent silent or automatic package updates. Block the threat actor’s command‑and‑control infrastructure (api.masscan.cloud, git‑tanstack.com, and *.getsession.org) at DNS or proxy level.
Security vendors and researchers named in the reporting include TanStack (post‑mortem), StepSecurity, Endor Labs, Aikido, Socket, SafeDep, and Snyk; each has published lists and guidance that defenders should consult for a complete view of affected packages.
The technical bluntness of this campaign is the lesson: stolen CI credentials and poisoned workflows can make malicious builds look legitimate. Defenders who rely on provenance alone are warned explicitly by Snyk and others to add behavioral checks at install time and to rotate credentials aggressively. The immediate task is triage — identify exposed packages, hunt for persistence, and revoke secrets — but the longer challenge is structural: rethinking how CI identities and supply‑chain attestations can be protected when attacker tradecraft targets the very systems that are supposed to guarantee integrity.
