CrowdSec TanStack Supply-Chain Incident: 170 Private Repositories Copied

By AiCybr Editorial · Published September 19, 2026

CrowdSec says an attacker copied about 170 of its private GitHub repositories on May 22, 2026, using a GitHub OAuth token associated with a recently departed employee. The company published its incident analysis on September 18 after an archive of its source code appeared online two days earlier. CrowdSec traced the token exposure to the May TanStack npm supply-chain compromise, tracked as CVE-2026-45321.

The incident provides a concrete downstream impact case for the TanStack compromise. GitHub's advisory says 84 malicious versions across 42 @tanstack/* packages were published on May 11. Installing an affected version could execute credential-stealing malware targeting GitHub tokens, SSH keys, npm credentials, cloud credentials, Kubernetes service-account tokens and HashiCorp Vault tokens.

CrowdSec says the copied material included private source repositories for its web console, data-science code and models, automation scripts, and the consensus system used to determine which IP addresses enter its community blocklists. The company says its production infrastructure and databases were not accessed through this incident and that the attacker did not alter its source code or build pipelines.

Incident timeline

CrowdSec says the Git history places the repository-copying activity between 05:52:29 and 06:01:33 UTC on May 22. Its investigation attributes the access to a GitHub OAuth token from the former employee's account. The employee had retained GitHub access temporarily to complete work after departure.

How the TanStack compromise exposed credentials

GitHub's advisory for CVE-2026-45321 describes a multi-stage compromise of TanStack's release path. The attacker chained a pull_request_target workflow weakness, GitHub Actions cache poisoning and extraction of an OIDC token from runner memory. The legitimate trusted-publisher identity then published the malicious packages.

The affected package artifacts contained an obfuscated router_init.js payload. Once executed during package installation, the malware searched the host for credentials and attempted to exfiltrate them. GitHub's advisory specifically lists GitHub tokens, SSH private keys, npm tokens, AWS and GCP credentials, Kubernetes tokens and Vault tokens among the targeted secrets.

That distinction matters operationally because remediation extends beyond removing an affected npm package. Any secret accessible to a developer workstation or CI runner that executed a malicious package belongs in the incident-response scope.

What CrowdSec says was exposed

CrowdSec's September 18 analysis says the archive contains source from more than 130 public repositories as well as private repositories. Private material included code for its console, data-science systems, automation and consensus logic.

The company also identified 83 CrowdSec user email addresses and information concerning 51 potential investors from 2020 in the exposed material. CrowdSec says it is contacting affected people and reporting the incident to relevant authorities.

The leak also exposed details of CrowdSec's consensus thresholds. CrowdSec says changing those thresholds is part of normal operations and that poisoning its community blocklist would still require detections from many trusted engines across separate networks.

CrowdSec identified one AWS SNS credential in the archive that remained usable within a narrowly scoped notification function. The company says an attempted use on August 17 did not progress beyond that limited permission. Other exposed tokens had been rotated, expired or were otherwise unusable from the internet according to its investigation.

Why offboarding became part of the blast radius

The stolen credential remained useful because the former employee's GitHub organization access was still active on May 22. CrowdSec removed that access on May 25.

This creates two separate control failures for defenders to model: a compromised developer endpoint supplied the credential, while retained repository access determined what that credential could reach. Either control can materially reduce the blast radius of a package-supply-chain incident.

Organizations using GitHub, GitLab or similar development platforms should therefore include source-control organization membership, OAuth grants, SSH keys, personal access tokens, package-registry credentials and cloud identities in the same offboarding workflow. Time-limited exceptions should have an explicit expiry rather than relying on a later manual cleanup.

What teams that used affected TanStack packages should do

GitHub's CVE-2026-45321 advisory says any developer or CI environment that ran npm install, pnpm install or yarn install against an affected TanStack version on May 11 should be treated as compromised. The response should focus on the host and every credential available to the install process.

1. Identify affected installs. Search lockfiles, package caches, CI logs and build artifacts for affected @tanstack/* versions from the May 11 incident window.
2. Isolate and inspect affected environments. Disconnect compromised workstations or runners from sensitive environments. On Linux and macOS, check for Shai-Hulud persistence such as gh-token-monitor before revoking credentials; variants can trigger destructive behavior when monitored tokens are revoked. Disable and remove persistence first, and perform credential rotation from a separate known-clean system.
3. Rotate reachable credentials from a clean system. Include source-control tokens, SSH keys, npm tokens, cloud credentials, Kubernetes service-account tokens, Vault tokens and other secrets present on the host or runner.
4. Review source-control access. Inspect repository reads, clones, OAuth activity and organization membership around the exposure period. A lack of code modification does not exclude repository exfiltration.
5. Rebuild compromised environments. Reinstall dependencies from known-clean versions and rebuild disposable CI runners or developer environments where practical.
6. Audit offboarding exceptions. Remove stale organization membership and revoke OAuth grants, PATs, SSH keys and package credentials that no longer have a current business purpose.
7. Reduce credential reach. Prefer short-lived, workload-scoped credentials for CI and keep developer tokens limited to the repositories and actions they actually require.

GitHub's advisory also recommends reviewing cloud audit logs for activity originating from affected hosts during and after the install window.

Provenance and release-pipeline security

The May TanStack incident is also significant because the malicious artifacts were published through the project's legitimate trusted-publisher path and carried valid provenance. Snyk and StepSecurity documented that the compromised workflow produced packages that could appear correctly attested even though attacker-controlled code had reached the release process.

Provenance remains useful for establishing where an artifact came from. This incident demonstrates the complementary requirement to secure the workflow, runner and code path that produce the artifact. Organizations using provenance should pair it with hardened GitHub Actions permissions, isolation of untrusted pull-request execution, ephemeral runners where appropriate, dependency controls and post-install credential monitoring.

Bottom line

CrowdSec's disclosure turns the May TanStack package compromise into a measurable downstream case: a stolen developer credential retained enough access for an attacker to copy a large private source corpus 11 days after the malicious npm packages were published.

For teams that encountered the affected packages, remediation should cover the compromised install environment, persistence checks, credential rotation from a clean system, source-control access review, and tighter offboarding and token-expiry controls.

Sources

• CrowdSec, TanStack Supply Chain Attack Analysis, September 18, 2026.
• GitHub Advisory Database, GHSA-g7cv-rxg3-hmpx / CVE-2026-45321.
• Snyk, TanStack npm Packages Compromised Inside the Mini Shai-Hulud Supply Chain Attack, May 11, 2026.
• StepSecurity, Mini Shai-Hulud Is Back: A Self-Spreading Supply Chain Attack Compromises TanStack npm Packages, May 11, 2026.