CrowdSec has disclosed that an attacker copied roughly 170 of its private GitHub repositories using credentials tied to a former employee whose access had not yet been fully revoked. The incident traces back to the May 2026 TanStack npm supply-chain attack, where malicious package versions were used to steal credentials such as GitHub tokens, SSH keys and cloud secrets from developers' machines. CrowdSec says the attacker used a GitHub OAuth token associated with the former employee on 22 May, several days after the malicious TanStack packages were published.
The copied repositories were not discovered immediately. The stolen code only surfaced publicly months later, appearing on an online forum on 16 September. Alongside the source code, the archive also contained 83 CrowdSec user email addresses and information relating to 51 potential investors from 2020, including names, email addresses and investment context.
A Former Employee's Access Became the Weak Point
The incident began with a fairly ordinary operational decision. CrowdSec had allowed a departing employee to retain GitHub access temporarily so he could finish some remaining work. Unfortunately, the employee's laptop had reportedly been compromised through the TanStack supply-chain attack, giving the attacker access to a valid GitHub OAuth token.
On 11 May, attackers had published 84 malicious versions across 42 TanStack npm packages, an incident now tracked as CVE-2026-45321. Installing one of those affected versions could execute malicious code capable of stealing sensitive developer credentials from the machine. CrowdSec says the former employee's token was then used 11 days later to copy the private repositories.
The company removed the former employee's GitHub account from its organisation on 25 May, three days after the repositories were copied. Other access had already been removed earlier, which CrowdSec believes is why it saw no suspicious activity inside its AWS environment. By the time the leak was discovered months later, the token itself no longer existed.
GitHub Logs Did Not Immediately Reveal the Token Activity
One complication was that CrowdSec says the OAuth token left no visible trace in the GitHub logs the company could access. Since the token had already disappeared by the time the investigation began, CrowdSec could not initially reconstruct exactly how it had been used.
GitHub support later traced the token's history and reportedly helped confirm CrowdSec's suspicion that the compromise was connected to the TanStack supply-chain incident. CrowdSec has not disclosed which specific malicious TanStack package reached the former employee's laptop or the exact date it happened.
The company also says it checked its developers' machines and found no further compromise. Similar cases affected other technology companies during the same TanStack incident, with Mistral AI reporting involvement of a developer device and OpenAI disclosing that two employee devices had been affected.
What Was Actually Inside the Leaked Repositories
The exposed material came from CrowdSec's private repositories, not its public open-source Security Engine. CrowdSec's public engine is used to detect malicious activity on servers and share information about hostile IP addresses, while the leaked repositories contained internal components and supporting systems.
According to the company, the archive included code for its web console, data science scripts and models, automation tools, and the consensus algorithm used to decide which IP addresses should be added to CrowdSec blocklists. The code was nearly four months old by the time it appeared publicly, and CrowdSec says it had changed significantly since then.
One particularly sensitive detail was the exposure of thresholds used by the consensus algorithm. These thresholds determine how much supporting evidence is required before an IP address is classified and added to the blocklist, and they had not previously been public.
CrowdSec Says the Blocklist Still Cannot Easily Be Poisoned
Despite the threshold information becoming public, CrowdSec says it does not believe attackers can realistically poison its blocklist by forcing legitimate IP addresses onto it. According to the company, doing so would require many detections from many trusted CrowdSec engines operating across separate networks, making the attack expensive and difficult to coordinate.
CrowdSec also notes that the thresholds are not fixed permanently. They can be changed and are already adjusted periodically as the platform evolves, meaning knowledge of an old threshold does not necessarily provide a lasting advantage to an attacker.
This is important because the consensus mechanism is central to the trust model behind the shared blocklist. If attackers could easily manipulate it, they could potentially cause innocent systems to be blocked. CrowdSec maintains that the safeguards around distributed detections still make that kind of abuse impractical.
Only One Credential Was Still Usable
CrowdSec says most credentials found inside the leaked repositories had already been rotated or were inaccessible from the public internet. The only credential believed to still have any practical value was tied to Amazon SNS, AWS's notification service.
Even that credential was heavily restricted. It could only publish messages to a single SNS topic rather than provide broader AWS access. CrowdSec says someone attempted to use it on 17 August, roughly a month before the stolen code appeared publicly, but the attempt did not progress any further.
The company rotated the exposed credentials on 16 and 17 September after learning about the leak. It also says no infrastructure or production databases were accessed and no source code was modified during the original GitHub compromise.
User and Investor Information Was Also Exposed
The leak was not limited purely to source code. CrowdSec says the archive contained email addresses belonging to 83 users, which had been retained by its data science team for research into how people were using the product. The company says it has around 150,000 users overall and intends to contact the individuals whose addresses were exposed.
The archive also contained information concerning 51 potential investors, including names, email addresses and notes relating to investment discussions from 2020. CrowdSec says the system containing those records had never been intended for public exposure.
CEO Philippe Humeau personally apologised to the affected investors and said the company would notify both the individuals involved and relevant authorities. While the dataset appears limited compared with a major customer database breach, the exposure still represents personal and commercially sensitive information that should not have become public.
CrowdSec Has Changed Its Endpoint Security Requirements
At the time of the original compromise, CrowdSec did not require endpoint protection software on every developer laptop. Following the incident, the company says it now deploys endpoint security software on devices used by staff who work with company code or systems.
That change is particularly relevant because supply-chain attacks increasingly target developer environments rather than production servers directly. A developer machine can contain source-code access tokens, SSH keys, cloud credentials and package-manager secrets, making it an attractive stepping stone into private repositories or infrastructure.
The TanStack attack demonstrates how a compromised dependency can bypass many traditional perimeter controls. The malicious code executes inside a trusted development environment, where credentials may already be available and the user may have significant privileges.
The Company's First Explanation Changed After Further Investigation
CrowdSec's 18 September report differs noticeably from the statement it published the previous day. The first statement claimed that no client data, names, credentials or other personal information had been leaked and described the impact as limited to the company itself.
That initial statement also suggested a component used internally by CrowdSec had likely been backdoored and used to steal an API key capable of reading private source code. The later investigation changed that explanation, finding no malicious TanStack versions inside CrowdSec's own codebase and instead identifying the former employee's compromised GitHub account as the likely entry point.
The second report also acknowledged the exposure of the 83 user email addresses and information relating to the 51 investors. This kind of revision is not unusual during incident response, where early conclusions can change as logs, external evidence and third-party investigations reveal more detail.
Why Offboarding Matters So Much
One of the clearest lessons from the incident is that account offboarding remains a critical security process. The former employee no longer needed normal organisational access, but GitHub access was intentionally left active so he could complete unfinished work. That temporary exception ultimately created the window the attacker used.
This does not mean organisations should never allow transition periods, but those situations need tighter controls. Temporary accounts should have clearly defined expiry dates, reduced permissions, stronger monitoring and ideally separate credentials from long-lived employee identities.
Offboarding becomes even more important in development environments, where a single GitHub token can potentially expose large amounts of proprietary code. Removing access quickly is one of the simplest ways to reduce the blast radius when a former employee's device or credentials become compromised.
Supply-Chain Attacks Continue to Target Developers
The broader TanStack incident is another reminder that software supply-chain compromises are increasingly effective because they exploit trust. Developers routinely install packages from npm and other ecosystems, often as part of automated builds or dependency updates. A malicious version can therefore reach privileged development machines through what appears to be a normal workflow.
Once installed, the malware does not necessarily need to attack production directly. Stealing tokens and SSH keys can be enough to give attackers legitimate access to repositories, cloud accounts or other internal services.
That makes dependency hygiene, endpoint protection, credential rotation and least-privilege access increasingly important. Organisations cannot assume that trusted package repositories guarantee that every package version is safe.
Final Thoughts
CrowdSec's incident is significant less because of what the attacker did with the repositories and more because of how the compromise happened. A former employee's GitHub access remained active, his laptop had been affected by a malicious npm package, and the stolen OAuth token was enough to copy around 170 private repositories without modifying the code or directly touching the company's production infrastructure.
The leak still exposed valuable internal information, including private source code, previously undisclosed blocklist thresholds, 83 user email addresses and details relating to 51 potential investors. CrowdSec says most credentials were already unusable, the blocklist cannot easily be manipulated, and there is no evidence that its core infrastructure or databases were compromised.
The larger lesson is familiar but important: developer access is infrastructure access. Supply-chain attacks increasingly target the credentials stored on developer machines because those credentials can provide a quieter route into private code and cloud environments than attacking production directly.
For organisations managing source code, the incident reinforces several basic controls that are easy to overlook—rapid offboarding, short-lived credentials, endpoint protection, least-privilege access and regular review of developer tokens. None of those controls is particularly glamorous, but as CrowdSec discovered, a single forgotten access path can remain valuable to an attacker long after everyone assumes it is no longer relevant.
Comments 0