CrowdSec Security Breach Exposes 170 Private GitHub Repositories After Developer Account Compromise

CrowdSec has issued its final incident report regarding a GitHub breach that occurred in May. The September 18 report confirmed that an attacker copied roughly 170 of CrowdSec’s private GitHub repositories. They later dumped them on an underground forum.

CrowdSec said the theft took place on May 22. The company linked the incident to the TanStack npm supply-chain attack earlier that month.

Timeline of the Theft

According to CrowdSec, the attacker copied the private repositories in just under 10 minutes between 05:52 and 06:01 UTC on May 22. They used an OAuth token belonging to a former CrowdSec developer.

The developer had already left CrowdSec. However, the company had not yet removed his GitHub access. CrowdSec said it kept the access active because the former employee wanted to finish some work. The company removed his account on May 25, three days after the theft.

The stolen archive also contained a Git configuration file with an OAuth token. By the time CrowdSec began its investigation, that token no longer worked. The case shows why companies need to remove developer access as soon as people leave.

TanStack Attack Provided the Entry Point 

The story starts with the TanStack npm attack. On May 11, attackers broke into the TanStack npm ecosystem. TanStack later said the attackers published 84 harmful versions of 42 @tanstack packages.

The attackers first gained access through GitHub Actions. They then used that access to publish malicious package updates. Those packages included code that could steal credentials.

The use of automation is also becoming a bigger part of modern cyberattacks. In another case, suspected ShinyHunters affiliates reportedly used Claude AI agents to automate parts of their attacks, showing how attackers can use automated tools to speed up malicious activity.

CrowdSec found TanStack packages in some of its own repositories. However, none of those packages were among the hacked versions. CrowdSec instead believes the wider attack led to the theft of the former employee’s credentials. The stolen OAuth token then gave the attacker access to CrowdSec’s private GitHub repositories.

That means the attacker did not need to break into CrowdSec’s main systems. The old developer access gave them another route to the code. CrowdSec says the attacker did not change its repositories during the incident.

The Leak Contained Private Code and Personal Data

The stolen archive contained CrowdSec’s private source code. That code covered parts of the company’s SaaS console, AWS cloud tools, connectors, and automation systems.

In addition, the archive also held more than 130 public repositories. Those repositories were already open to the public, so their exposure did not create the same risk.

The private repositories contained some personal data as well. CrowdSec found email addresses linked to 83 users. The company said its data science team kept those addresses to study product use and user feedback.

The archive also contained the names and email addresses of 51 people who had considered investing in CrowdSec in 2020. CrowdSec said it plans to contact the affected people. It also plans to notify the relevant authorities.

The company stressed that the attacker did not reach its databases or main infrastructure. That limits the confirmed impact. CrowdSec has confirmed the loss of private source code and some personal data, but not a wider system breach.

No Code Changes Found

CrowdSec found no sign that the attacker changed its source code. The company also found no evidence of changes to its build systems or infrastructure. The attacker appears to have used the stolen access to copy repositories and nothing more. Also, CrowdSec found no commits linked to the attack.

CrowdSec also checked the secrets and credentials stored in the stolen code. It says the majority of the credentials have either already expired or have been revoked. One AWS token still worked. CrowdSec said the token had very limited power. It could only publish messages to one Amazon SNS topic.

CrowdSec also found signs that someone tested the token on August 17. Those tests checked the token’s identity and the topics it could reach. CrowdSec said the token could not give the attacker wider access.

The Leak Stayed Hidden for Months, Raising a Key Security Issue

The repository theft happened in May. CrowdSec did not discover it until September 16. That day, the stolen archive appeared on a forum. Fuites Infos alerted CrowdSec of the leak and provided the archive, and the company’s response team then started investigating it the same day.

In addition to forensic review, CrowdSec also rotated affected credentials. But the long delay created another problem. Older GitHub activity can become harder to trace because GitHub does not keep every type of audit data forever.

GitHub says Git events in Enterprise Cloud audit logs have a seven-day retention period. CrowdSec said the stolen token had already expired or had been removed by the time the company found the leak.

GitHub support later helped CrowdSec rebuild the timeline. That work helped confirm that the former employee’s account handled the repository copies.

CrowdSec Tightens Access Controls

CrowdSec says it has since changed several security controls. The company now uses tighter access limits and stronger separation between different levels of access. It also tightened controls for users, apps, and automated systems.

The incident highlights a basic security rule that companies often overlook: remove access when a developer leaves. In this case, an attacker stole a developer token during a wider supply-chain attack. The attacker then used access that CrowdSec had not yet removed. The result was private-code theft that stayed hidden for almost four months.

CrowdSec says its core systems and databases remain outside the confirmed impact. But the incident shows how a short-lived supply-chain attack can create problems long after the original breach ends.