CrowdSec loses 170 private repos to the TanStack npm chain and a botched offboarding
On September 18, 2026, CrowdSec revealed that an attacker copied about 170 private GitHub repositories in May using the account of a former employee whose access had never been revoked. The initial compromise came from TanStack’s malicious npm packages, which also hit Mistral AI and OpenAI.
September 18, 2026. CrowdSec admits an attacker copied about 170 private GitHub repositories on May 22, using the account of an employee who had just left the company. May 11. TanStack’s malicious npm packages were published, planting the first seed. September 16. The copied code appears on a forum. Why it matters: this is not one failure but two independent failures chained together — a compromised software supply chain and a botched offboarding — showing how a French security vendor can itself get its code stolen.
The TanStack chain: 84 poisoned npm packages
The entry point is a textbook supply chain attack on the npm ecosystem. On May 11, 2026, 84 malicious versions of 42 TanStack packages were published. The incident is tracked as CVE-2026-45321. Installing one of those versions ran code that stole credentials from the developer’s machine: GitHub tokens, SSH keys, and cloud credentials.
The CrowdSec employee in question had installed one of those packages on his laptop. The resulting token theft is the link that, eleven days later, enabled the repository copy. The supply chain is not a metaphor: a legitimate, popular package was swapped for a poisoned version, and developers’ implicit trust in npm install did the rest.
The same attack reached other companies in France and the United States. Mistral AI said a developer device was involved in its case. OpenAI said two employee devices were affected, with unauthorized access to a limited subset of its internal code repositories. CrowdSec, Mistral AI, and OpenAI: three AI and security vendors, one single vector.
The copy: a departure whose access survived
The second link is more embarrassing, because it is entirely internal. The attacker copied the repositories with a GitHub OAuth token belonging to a former employee. CrowdSec had kept his GitHub access open so he could finish some work — a common practice, and one rarely questioned at the moment of departure.
The timeline is damning. The copy happened on May 22. CrowdSec only removed the account from its GitHub organization on May 25 — three days after the copy, and months before it learned of the leak. The token left no trace in the GitHub logs it could check and no longer existed when the company discovered the theft. It was GitHub support that traced the token’s history and confirmed TanStack as the source.
The copied code was not modified: infrastructure and databases were untouched. But what leaked is substantial. The archive includes CrowdSec’s web console, its data science scripts and models, its automation scripts, and most importantly the consensus algorithm that decides which IP addresses enter the shared blocklists.
What the leak held, and what it did not
The archive posted on September 16 to a forum also contained personal data: the email addresses of 83 CrowdSec users, and the names, emails, and investment context of 51 potential investors dating back to 2020. CEO Philippe Humeau wrote to the investors to “personally apologize” — a rare admission in this kind of incident.
CrowdSec’s impact analysis aims to reassure on one specific point: the blocklist cannot be poisoned. Doing so would require, according to the company, tens of detections from tens of trusted engines across tens of separate networks, at great cost. The company can also change the algorithm’s thresholds, as it often does.
One detail says a lot: the only usable credential in the leak was access to the AWS SNS notification service, limited to publishing to one topic. Someone tried to use it on August 17, a month before the code was posted, and got no further. The other tokens had already been rotated or could not be reached from the internet.
The devops lesson: automate what humans forget
The CrowdSec incident is less a story of sophisticated malware than of broken process. Two things would have stopped it, and neither is technologically difficult.
The first is automated revocation. Keeping a departed employee’s access open “to finish some work” is the implicit rule in many teams, and it is exactly the window the attacker exploited. An offboarding flow that mechanically revokes GitHub, SSH, and cloud access at the moment of departure — with no manual exceptions — closes that link. The second is endpoint protection on developer machines: CrowdSec did not require endpoint protection software at the time, and now runs it on the laptops of staff who work with its code or systems.
Dependency-side verification is a two-step job with the tools already at hand:
# Audit the project's npm dependencies and flag known vulnerabilities
npm audit --omit=dev
# Verify installed package integrity against the lockfile
npm ci --ignore-scripts && npm ls --depth=0The --ignore-scripts flag is not a detail: it is the install scripts (preinstall, postinstall) that poisoned packages use to run. Disabling them by default, and re-enabling them only for packages whose provenance you have verified, directly shrinks the surface of this attack.
Verdict
CrowdSec lost 170 private repositories not to a zero-day exploit but to two process failures that compounded: a compromised npm dependency and an unrevoked departure access. If you manage private repositories, automate access revocation at offboarding — it is the highest-return measure in your whole security program. If your developers install npm packages, audit your dependencies, disable install scripts by default, and deploy endpoint protection on machines that touch code. Both lessons cost less than the day you find your own code on a forum.