The CrowdSec source code leak was a private-repository theft, not a confirmed compromise of CrowdSec production infrastructure or software integrity. CrowdSec says an attacker used a GitHub OAuth token linked to a recently departed employee to clone about 170 private repositories on May 22, 2026. Its final investigation says the employee’s environment had been compromised through the earlier TanStack npm supply-chain incident.
What happened in the CrowdSec source code leak?
CrowdSec says roughly 170 private GitHub repositories were cloned within minutes using an OAuth token associated with a recently departed employee. CrowdSec says GitHub support helped trace the access to that account and that its investigation linked the employee compromise to the May TanStack supply-chain attack.
CrowdSec says the copied material included private source code and limited personal and credential data, but that its production infrastructure and databases were not accessed and no code, CI system or build pipeline was altered.
When was the CrowdSec source code actually stolen?
The repository cloning happened on May 22, 2026, not in September. CrowdSec’s final report places the cloning activity between approximately 05:52 and 06:01 UTC.
The incident became public months later. CrowdSec says it learned of the leaked source archive on September 16 and then completed the deeper forensic analysis that connected the repository activity to the compromised GitHub identity.
How did the TanStack supply-chain attack lead to CrowdSec?
The upstream TanStack incident occurred earlier in May. TanStack’s own postmortem says malicious versions of dozens of npm packages were published and could harvest credentials from developer and CI environments, including GitHub, npm, cloud and SSH credentials.
CrowdSec says the employee account later used to access its private repositories had been compromised through that TanStack supply-chain event. GitHub support then helped CrowdSec trace the OAuth token used for the repository cloning back to the former employee’s account.
This creates a broader security chain: a poisoned dependency compromises a developer environment, a privileged repository token is stolen, and that token remains useful long enough to become a separate private-source-code incident.
Why did a former employee still have GitHub access?
CrowdSec says the employee had recently left but still retained GitHub access for legitimate finishing work. The company removed that access on May 25, three days after the repository cloning.
The security lesson is not simply that a former employee had access. The more important issue is that a token associated with a compromised developer identity remained capable of reading private repositories during an access-transition period.
How many CrowdSec repositories were exposed?
CrowdSec says approximately 170 private repositories were cloned. Some reporting refers to roughly 300 repositories because more than 130 already-public repositories were also part of the larger repository set.
The security-sensitive number is therefore the approximately 170 repositories containing material that was not intended to be public.
What private CrowdSec code was exposed?
CrowdSec says the copied repositories included several categories of private internal code, including:
- SaaS Console source code;
- data-processing scripts and models;
- parts of the company’s consensus-algorithm implementation;
- automation, deployment and testing scripts;
- other private development material.
Exposure of private source code can help an attacker study internal architecture or search for weaknesses, but possession of source code does not itself prove that the company’s production systems were compromised or that its distributed software was modified.
Were CrowdSec production infrastructure or databases compromised?
CrowdSec says no. Its final analysis says production infrastructure and databases were not accessed or compromised.
That distinction should remain explicit. The evidence currently supports unauthorized repository read access and source-code exposure, not a broader compromise of CrowdSec’s production environment.
Was CrowdSec software or its build pipeline tampered with?
CrowdSec says it found no evidence that the attacker modified source code, committed malicious changes or altered its CI or build pipelines.
The company says the compromised GitHub account was used for repository cloning rather than code modification. Based on the reviewed evidence, TPS should not describe this incident as a CrowdSec software-supply-chain compromise or claim that malicious CrowdSec builds were shipped.
What credentials were exposed?
CrowdSec says its repository review found one credential that was still usable at the time of investigation: a tightly scoped AWS SNS credential. The company says other discovered credentials had already been rotated, revoked or were not usable from the public internet to its knowledge.
The AWS credential’s scope matters. CrowdSec says it was restricted to publishing to a single SNS topic. It should not be described as a credential providing unrestricted AWS-account access.
Was the AWS SNS credential actually abused?
CrowdSec says someone probed the AWS SNS credential on August 17 using calls that appeared intended to determine what permissions it had. CrowdSec says the credential’s limited scope prevented the activity from progressing further.
The reviewed evidence supports a credential-permission probe, not a claim that the attacker gained broad AWS control or caused a known production outage.
Was CrowdSec customer data exposed?
CrowdSec says its customer databases were not accessed and that client account credentials, organization data and client logs were not part of the exposed dataset.
The company did identify limited personal information elsewhere in the copied repositories. That should not be expanded into a general customer-database breach.
What personal information was exposed?
CrowdSec says the leaked material included:
- email addresses associated with 83 users used in data-science work;
- names and email addresses relating to 51 potential investors from 2020;
- historical investment-related context associated with those potential investors.
The company did not describe this as a copy of its customer-account database.
Was CrowdSec’s Security Engine or blocklist compromised?
CrowdSec’s Security Engine source code is public by design, and CrowdSec says the incident did not alter its software or compromise its production systems.
The exposed private repositories did contain implementation details relevant to internal systems, including parts of its consensus logic. That can create residual security-research risk, but the reviewed evidence does not establish that attackers poisoned CrowdSec’s blocklists or compromised the broader consensus network.
Do CrowdSec customers need to rotate their passwords?
The reviewed incident evidence does not establish that CrowdSec customer passwords were stolen. TPS therefore should not issue a blanket customer-password rotation instruction solely because of this incident.
Customers should follow any direct CrowdSec notification that applies to their account or environment. Organizations using CrowdSec should also keep the product current and monitor CrowdSec’s incident updates in case the exposure scope changes.
Is TanStack still compromised?
TanStack’s incident occurred in May. TanStack subsequently issued an all-clear and said the malicious versions had been removed and that currently available versions were safe.
That does not erase downstream exposure created while the malicious packages were active. A credential stolen in May can continue to matter later if the token, session or account remains valid.
What should software companies learn from the CrowdSec incident?
Treat package compromise as an identity incident
Removing a malicious dependency is not enough. Investigate tokens, browser sessions, SSH keys, cloud credentials and repository credentials that were accessible from the affected developer environment.
Revoke repository tokens and sessions
Invalidate GitHub OAuth tokens, personal access tokens and other repository credentials that may have been reachable from a compromised machine.
Review repository access logs
Look for clone, fetch, archive and API activity that may represent data theft even when no commits or source changes occurred.
Tighten employee offboarding
Temporary post-departure access should be narrowly scoped, explicitly time-bounded and monitored. Remove access immediately when the remaining business need ends.
Rotate exposed cloud secrets
Repository review should identify cloud, messaging, deployment and service credentials. A credential with limited scope still needs investigation and rotation when exposed.
Verify code integrity separately
Source-code theft and source-code tampering are different states. Check commits, branch protections, CI logs, build provenance and artifact integrity before claiming a software-supply-chain compromise.
What is confirmed and what remains unresolved?
| Question | Current evidence state |
|---|---|
| Were private CrowdSec repositories cloned? | Confirmed by CrowdSec |
| How many private repositories? | Approximately 170 |
| When did cloning occur? | May 22, 2026 |
| Was a GitHub OAuth token used? | Confirmed by CrowdSec’s investigation |
| Was the account tied to a departed employee? | Confirmed by CrowdSec |
| Does CrowdSec link the employee compromise to TanStack? | Yes |
| Were production systems or databases accessed? | CrowdSec says no |
| Was source code or CI modified? | CrowdSec says no |
| Were customer passwords exposed? | Not established |
| Has leaked code been maliciously reused? | Unknown |
CrowdSec source code leak: direct answers
Was CrowdSec hacked through TanStack?
CrowdSec says a developer account was compromised through the TanStack supply-chain incident and the resulting GitHub OAuth credential was later used to clone private CrowdSec repositories.
Did attackers steal CrowdSec customer databases?
CrowdSec says no. It reports no access to its production infrastructure or databases.
Did attackers backdoor CrowdSec software?
No such modification was established. CrowdSec says no code, CI or build pipeline was altered.
Were all 300 repositories private?
No. CrowdSec says approximately 170 were private; more than 130 others were already public.
Should all CrowdSec users rotate passwords?
The reviewed evidence does not support blanket password rotation because CrowdSec has not reported customer password exposure from this incident.
Could the leaked source create future risk?
Yes. Private implementation details can help attackers study internal architecture or search for vulnerabilities, so evidence of later code abuse is an important update trigger.
Verification method
ThePulseSignal reviewed CrowdSec’s final incident analysis and reconciled it with TanStack’s supply-chain postmortem and security advisory plus current security reporting. TPS separated repository read access, exposed credentials and personal data from unproven production, database or build-system compromise.
Limitations
Independent attacker attribution, the exact malicious TanStack package or version on the former employee endpoint, complete downstream distribution of the leaked archive, undiscovered credentials and malicious reuse of the exposed CrowdSec code remain unresolved.