Cyber & AI intelligence
Wasteland.
Briefs indexed2769
Issues28
Published Mondays07:30 CT
▣ Breach CROWDSEC-TANSTACK- 2026-09-19

CrowdSec: TanStack npm Supply Chain Compromise Leads to Private Repo Theft

"French security vendor CrowdSec has confirmed that an attacker used the still-active GitHub account of a departed employee to clone roughly 170 of its private repositories on 22 May 2026, and that the intrusion almost…"

French security vendor CrowdSec has confirmed that an attacker used the still-active GitHub account of a departed employee to clone roughly 170 of its private repositories on 22 May 2026, and that the intrusion almost certainly traces back to the TanStack npm supply-chain compromise eleven days earlier. The company did not learn of the theft until 16 September, when the stolen code surfaced on a leak forum, closing a detection gap of nearly four months. CrowdSec maintains that its infrastructure, databases and customer data were untouched, and that the attacker only read code rather than modifying it.

What Happened

CrowdSec published a short statement on 17 September and a longer technical post-mortem on 18 September. According to that timeline, on 11 May 2026 an actor the company identifies as TeamPCP (also tracked as UNC6780) backdoored the TanStack npm packages with credential-harvesting malware CrowdSec names as "Shai Hulud." One of CrowdSec's developer laptops, belonging to an employee who had recently left the company, was compromised in that campaign.

CrowdSec had deliberately left that person's GitHub access open so he could finish outstanding work. On 22 May, between 05:52:29 and 06:01:33 UTC, a GitHub OAuth token tied to his account was used to download the private repositories. CrowdSec's own analysis attributes the download to a BreachForums founder and a member using the handle diencracked, operating from an IP address in Toronto, Canada, on a machine set to UTC-4. That attribution rests solely on CrowdSec's reading of Git metadata and is the company's claim, not an independent finding. Notably, the same day TeamPCP publicly claimed responsibility for compromising Mistral AI repositories, which suggests either a shared toolset or a handoff of harvested tokens between the initial intruder and whoever performed the clone.

CrowdSec removed the ex-employee's account from its GitHub organisation on 25 May, three days after the copy and months before it knew a breach had occurred. The company says his other credentials had already been revoked, which it offers as the explanation for why no suspicious activity appeared in its AWS environment. The token itself left no trace in the GitHub audit logs available to CrowdSec and had already expired by September; the company says GitHub support later reconstructed the token's history and confirmed TanStack as the origin. CrowdSec has not said which specific malicious package reached the laptop or when, and its public report does not include GitHub's own findings.

What Was Taken

The headline figures differ, and the difference is mostly arithmetic rather than dispute. Heise Online reported that "over three hundred repositories fell into the wrong hands," while The Hacker News, Undercode News and CrowdSec's own analysis all put the private repository count at roughly 170. CrowdSec addressed the gap directly in its statement: the 300 figure is accurate only when the 130-plus public repositories are included, and those hold the open-source Security Engine, which is public by design and therefore out of scope. The company also argues the repository count is a poor proxy for volume, reflecting how the codebase is subdivided more than how much code was taken.

The private side contained the source for CrowdSec's SaaS console, some AWS cloud routines, connectors and automations, plus at least one API token used by the CI/CD component itself.

On personal data, the accounts do not line up cleanly. CrowdSec's 17 September statement says flatly that no client data, login credentials, names or organisations were leaked, and that the company does not store PII or client logs; Heise, GoKawiil and RuntimeWire all reflect that position. The Hacker News, however, reports that the archive posted on 16 September also contained the email addresses of 83 CrowdSec users along with the names, email addresses and investment context of 51 prospective investors from 2020, and attributes that detail to the company. That claim appears in only one source and should be treated as unconfirmed pending clarification from CrowdSec, but it materially qualifies the "no personal data" framing and deserves a direct answer.

Why It Matters

The strategic lesson here is not that a security vendor got breached, it is the shape of the chain. A poisoned dependency on a developer workstation converted into a long-lived OAuth token, which converted into bulk repository access at an entirely different organisation, days after the malicious packages themselves had been pulled. Removing the bad package does not remove what it stole.

The second lesson is offboarding. CrowdSec made a defensible operational choice, keeping a departing engineer's GitHub access alive so he could wrap up work, and that single lingering grant became the pivot. The account was cut on 25 May for unrelated hygiene reasons, three days too late, and the company then spent four months unaware anything had happened.

Third, the detection failure is instructive: a nine-minute mass clone of 170 repositories produced nothing actionable in the logs CrowdSec could access. Outside notification, not internal telemetry, closed the loop. CrowdSec's own framing is that the leaked code has limited standalone value because its product depends on network effect rather than algorithms, and that four months of development have since moved the codebase on. That is plausible, but it does not cover the embedded CI/CD token or any secret the company has not yet found. CrowdSec says it has rotated all access rights and is actively hunting for backdoors and leaked credentials, and has found none so far.

The Attack Technique

The upstream compromise is tracked as CVE-2026-45321, rated CVSS 9.6, and was added to CISA's KEV catalogue on 27 May 2026. Per analysis from Safeguard Research, the attacker published 84 malicious versions across 42 @tanstack/* packages inside a six-minute window on 11 May, and did so through TanStack/router's legitimate GitHub Actions OIDC trusted-publisher binding. The publish workflow itself was never modified.

Instead, three individually well-documented weaknesses were chained: a pull_request_target "Pwn Request" misconfiguration, GitHub Actions cache poisoning across the fork-to-base trust boundary, and runtime extraction of the OIDC token directly from the Actions runner process memory. Chaining them let the attacker ship credential-stealing malware under TanStack's genuine publisher identity. TanStack's advisory, as cited by CrowdSec, states that installing an affected version executed code that harvested GitHub tokens, SSH keys and cloud credentials from the developer's machine. That is precisely the class of artefact used against CrowdSec eleven days later.

What Organizations Should Do

  1. Treat offboarding as a same-day revocation event with no exceptions. If a departing engineer genuinely needs to finish work, scope the access to specific repositories with a hard expiry date, and audit those grants weekly rather than trusting anyone to remember.
  2. Inventory and expire OAuth tokens and PATs independently of accounts. CrowdSec's token survived the user's practical departure and left no usable audit trail. Enforce short token lifetimes, require SSO reauthorisation for organisation access, and alert on tokens with broad repo scope.
  3. Alert on bulk clone behaviour. A single identity pulling 170 repositories in nine minutes is a detectable signal. Feed GitHub audit and Git event data into your SIEM and build a rate-based rule for clone volume per user per hour.
  4. Audit your pull_request_target workflows and Actions cache trust boundaries now. The TanStack chain required no novel technique. Review every workflow that runs with elevated permissions against untrusted fork content, and treat cache entries crossing the fork-to-base boundary as attacker-controlled.
  5. Assume developer workstations are credential reservoirs and reduce what sits on them. Move cloud credentials to short-lived, hardware-bound or workload-identity issuance, keep SSH keys on hardware tokens, and pin dependency installs with lockfiles plus --ignore-scripts where feasible.
  6. Rehearse the "four months later" scenario. Build the capability to answer, retrospectively, which tokens existed on a given date, what they could reach, and what they did. CrowdSec needed GitHub support to reconstruct that history; your incident should not depend on a vendor's goodwill.

Sources: CrowdSec Says TanStack npm Attack Led to Copy of 170 Private GitHub... | Supply chain attack: CrowdSec source code exfiltrated by unknown pa... | TanStack Supply Chain Attack Analysis | CrowdSec Statement: Source Code Exposure in May 2026 | CrowdSec says a poisoned TanStack package exposed its private sourc... | CrowdSec GitHub Breach Exposes Private Code After Former Employee’s... | CrowdSec Source Code Leak - GoKawiil | TanStack npm Compromise and ASUS Live Update Backdoor: Two Supply C...