TanStack Supply Chain Attack Led to CrowdSec Source Code Leak, Investigation Finds

CrowdSec has traced a source code leak discovered in September 2026 to a supply chain compromise involving TanStack packages and a former employee’s GitHub account, according to the company’s final incident analysis published on September 18.

The cybersecurity company said attackers obtained access to private repositories belonging to its GitHub organisation in May, several months before the leaked archive appeared on a cybercrime forum. CrowdSec’s investigation found that the compromised account was used to clone repositories, but not to modify source code, infrastructure or continuous integration and continuous delivery (CI/CD) pipelines.

The incident illustrates how a compromise originating in the software ecosystem can extend into an organisation’s development environment, even when the affected company has security controls in place.

CrowdSec said its investigation found no evidence that its infrastructure or databases had been accessed or compromised. The company also reported that no code was altered and that the exposed credentials did not provide attackers with unrestricted access to its cloud environment.

The findings provide a detailed example of how an attack involving software dependencies can lead to a separate exposure of proprietary code, while also highlighting the importance of identity lifecycle management, credential restrictions and endpoint security.

How the incident unfolded

CrowdSec’s timeline connects the source code exposure to a series of events beginning in May 2026.

The company’s report identifies May 11 as the date when 42 packages associated with TanStack were backdoored with Shai Hulud malware, which the report describes as specialised in harvesting credentials and tokens.

On May 22, an individual using the name diencracked, whom CrowdSec identifies as a BreachForums founder and member, downloaded the contents of approximately 170 private CrowdSec GitHub repositories.

CrowdSec’s Git data placed the activity between 05:52:29 and 06:01:33 UTC. The company said the archive contained repository history consistent with a May 22 collection date.

The report also describes a separate credential-related event on August 17, when an AWS token associated with Simple Notification Service (SNS) was tested to determine its permissions.

The incident became public on September 16, when an archive containing CrowdSec source code was published on a cybercrime forum.

CrowdSec contacted the forum’s staff that evening and established a crisis response team. Initial forensic investigations and credential rotations followed overnight, with further investigation and reporting continuing on September 17.

GitHub subsequently helped CrowdSec reconstruct the token’s lifecycle and identify the connection to the compromised former employee account.

The company published its final analysis on September 18.

From a compromised dependency to private repositories

The investigation’s central finding is that the initial supply chain compromise affected an employee’s access rather than directly compromising CrowdSec’s production infrastructure.

CrowdSec said GitHub’s support team helped trace the repository download to a former employee whose account remained part of the organisation after the individual had left the company.

The employee had retained access for a legitimate reason: they were expected to complete some outstanding work. CrowdSec said the employee’s GitHub access was revoked on May 25, three days after the repository download.

The company concluded that the former employee’s account had been compromised through the TanStack supply chain attack. According to the report, the account was used solely to clone repositories.

No commits or changes to source code, infrastructure or CI/CD were identified in the investigation.

This distinction matters because repository access and production system access are not equivalent. An attacker who can read private source code may gain visibility into an organisation’s implementation, but that does not automatically provide the permissions required to change software or access production data.

CrowdSec’s findings indicate that the attacker obtained a substantial collection of source code without establishing a corresponding ability to alter the company’s systems.

The report also highlights the challenges of reconstructing activity involving credentials that no longer exist. CrowdSec could not initially identify the origin of the OAuth token through its available GitHub audit records.

The token had been created, used and expired before the company became aware of the leak. GitHub’s investigation provided additional information that helped establish its lifecycle and connect the activity to the compromised account.

What was exposed, and what was not?

CrowdSec said the leaked archive contained source code from more than 130 public repositories and numerous private repositories.

The company characterised the incident as a source code exposure rather than a compromise of its infrastructure or databases.

Its assessment covered several categories of material.

Proprietary application code

The leaked material included the source code for CrowdSec’s Console, the company’s SaaS interface.

CrowdSec said the Console depends on its AWS infrastructure and supporting microservices, and that the code was not designed as a standalone open-source project.

The company acknowledged that access to the source code could h elp an attacker research potential weaknesses. However, it said the code did not contain secrets and that the rapidly changing codebase had already evolved significantly by the time the leak became public.

The report does not identify a specific vulnerability discovered or exploited through analysis of the exposed Console code.

Data science code and models

The archive also included some data science scripts and models.

CrowdSec said these materials had limited value without the data used to train the models or supply the scripts. The company also confirmed that its Consensus Algorithm was included in the exposure.

The algorithm contributes IP addresses to blocklists based on observations from the CrowdSec network.

According to the company, its design requires multiple detections from vetted security engines distributed across different Autonomous Systems. The report says the undisclosed thresholds governing detection volume and diversity were the main elements of the algorithm that had not previously been made public.

CrowdSec said it did not believe the leak made the algorithm directly susceptible to poisoning or compromise.

However, it acknowledged that exposing the thresholds could give a motivated attacker additional information about the conditions needed to influence blocklist decisions.

The company said those thresholds can be adjusted and that it would continue monitoring for discrepancies.

Automation scripts

The leak included various internal automation scripts, covering activities such as Slack notifications, content publication, testing, quality assurance and deployment.

CrowdSec assessed these materials as presenting no risk to customers, the network or data integrity.

Credentials and personal information

The company reported that most secrets in the exposed source code had already been revoked or rotated.

One usable credential was an AWS token scoped to publishing notifications through a specific SNS topic. CrowdSec said the token did not provide broader permissions.

The company also identified limited personal information in the archive, including 83 email addresses associated with data science usage monitoring and 51 potential investors’ names, email addresses and investment context from 2020.

CrowdSec said it would contact affected individuals and report the investor information exposure to the appropriate authorities.

Why the source code exposure did not become a reported infrastructure compromise

A central aspect of CrowdSec’s assessment is the separation between access to source code and access to operational systems.

The company said its infrastructure uses AWS serverless services and makes extensive use of AWS Systems Manager (SSM) and Secrets Manager. This reduces the number of credentials stored directly in source code, although it does not eliminate the possibility of credential exposure.

CrowdSec also described strict privilege separation and tightly scoped permissions for users, applications, AI systems, cloud routines and scripts.

The exposed SNS token provides a concrete example of how such restrictions can limit the impact of a credential leak.

CrowdSec said the token was tested on August 17 using AWS operations including GetCallerIdentity and ListTopics. The company reported that the associated role was restricted to publishing on a single SNS topic and that the activity did not go further.

The report does not indicate that this token enabled access to customer databases or production infrastructure.

For organisations operating cloud-based applications, the distinction is important: the presence of a cloud credential in an exposed repository does not by itself establish the level of access an attacker obtained.

The actual impact depends on the credential’s permissions, whether it remains valid, the systems it can reach and the ability to detect and investigate its use.

CrowdSec’s account suggests that permission restrictions limited the usefulness of the exposed credential. Its findings also show why organisations need to investigate each credential individually rather than treating all leaked secrets as equally powerful.

The limits of repository audit visibility

CrowdSec’s investigation also highlights a challenge for security teams: reconstructing Git activity after a credential has expired or disappeared.

The company initially found no evidence of the relevant OAuth token in its organisation’s audit logs or the logs of current GitHub organisation members.

CrowdSec said GitHub audit logs cover specific actions and that its subscription did not provide the rolling Git activity visibility available through certain enterprise plans.

The company therefore relied on GitHub’s assistance to obtain information about repository activity during the relevant period.

This helped identify the former employee account and establish that the account had been used to download repositories.

The case illustrates the importance of retaining sufficient identity and repository activity records to investigate incidents that may not be discovered immediately.

It also shows that forensic investigations can depend on information held by a service provider, particularly when the relevant access token no longer exists.

For security teams, the practical question is not simply whether audit logging is enabled. It is whether the available records capture the activities needed to reconstruct an incident, and whether those records remain accessible for long enough.

Why existing security controls did not prevent the attack

CrowdSec said it already had multiple security mechanisms in place before the incident.

These included two-factor authentication, passkeys and physical security keys, password management tools, privilege separation, internal and external audits, penetration testing, automated code analysis and employee onboarding and offboarding procedures.

The company also described package-age monitoring designed to avoid using Node.js dependencies that are either too new to have been adequately reviewed or too old to remain appropriate.

Despite these measures, the supply chain compromise still resulted in unauthorised repository access.

CrowdSec’s analysis identifies an important gap: at the time of the incident, it did not enforce endpoint detection and response (EDR) on developer machines.

The company has since introduced endpoint protection that focuses on malicious packages and extensions. It said workstations and laptops used to access its codebase or infrastructure now run Aikido Security’s EDR.

CrowdSec also noted that runtime monitoring and in-memory analysis, such as capabilities offered by other EDR products, could provide additional coverage.

The company acknowledged that endpoint protection might not have been present on the former employee’s device after their departure.

This is a critical detail. Endpoint controls introduced after an incident cannot retroactively protect a machine that has already been compromised, particularly when that machine is no longer under the organisation’s direct management.

The incident therefore demonstrates the limits of relying on any single control. Authentication, least privilege, dependency review, endpoint monitoring and offboarding address different parts of the attack path.

What enterprises can learn from the incident

CrowdSec’s experience offers several practical lessons for organisations that rely on open-source software, third-party packages and distributed development teams.

Treat dependency security as an identity security problem

A malicious package can create risks that extend beyond the application in which it is installed.

If a developer environment contains credentials that can access private repositories, a compromised dependency may provide an attacker with a route to sensitive source code.

Organisations should therefore consider which identities and credentials are available to developer machines, not just whether application dependencies pass security checks.

Make offboarding a complete access lifecycle

CrowdSec retained the former employee’s GitHub access temporarily for legitimate work-related reasons.

The incident shows how such exceptions can become relevant when a user’s device or account is subsequently compromised.

Companies should explicitly track temporary access extensions, assign ownership for their review and ensure that access is removed when the business requirement ends.

This includes checking repository permissions, cloud credentials, OAuth integrations, CI/CD access and other connected services.

Restrict credentials to specific tasks

CrowdSec’s SNS example illustrates how narrowly scoped permissions can constrain the usefulness of an exposed credential.

Security teams should assess whether each identity or token has only the permissions needed for its task, including automated systems and cloud routines.

The objective is to limit what a compromised identity can do, even if preventive controls fail.

Improve endpoint visibility

CrowdSec’s decision to introduce endpoint protection reflects its assessment that developer workstations need additional safeguards against malicious packages and extensions.

For organisations, endpoint monitoring should be considered alongside dependency scanning and repository access controls.

The exact monitoring approach will depend on the development environment, operating systems and existing security tooling.

Preserve forensic evidence

The investigation depended on GitHub’s assistance because the relevant OAuth token had already expired.

Security teams should understand what repository and identity activity their current plans record, how long those records remain available and whether they can obtain additional evidence from service providers.

These preparations can reduce uncertainty when an incident is discovered weeks or months after the initial compromise.

CrowdSec’s response and next steps

CrowdSec said the incident required approximately 48 hours to complete its initial inventory, credential rotation, forensic investigation and public communications.

The company believes a future response could be completed in under 24 hours, based on lessons from the investigation.

It also said it would continue monitoring logs, audit trails and system behaviour for activity that deviates from normal patterns.

The report does not describe a specific new product or a broader commercial offering resulting from the incident. Instead, it focuses on operational changes, including endpoint protection and improvements to the company’s security response.

CrowdSec also acknowledged that the source code leak created reputational and communication challenges, even though its investigation did not identify a compromise of production infrastructure or customer databases.

The company said it received support from security industry peers, customers, partners and GitHub during the response.

Its final assessment is that strict privilege separation, restricted cloud permissions and the revocation of the former employee’s core access limited the attacker’s ability to move beyond repository collection.

A supply chain incident with a wider security lesson

The CrowdSec incident highlights how software supply chain attacks can affect organisations through the development tools and identities used to build and maintain software.

The reported exposure did not involve a confirmed compromise of CrowdSec’s production infrastructure, but it demonstrated that private source code can still be accessed through a compromised developer identity.

The company’s findings also underline the value of separating repository permissions from cloud infrastructure access, restricting credentials to specific functions and maintaining enough forensic visibility to reconstruct activity after the fact.

For enterprise security teams, the lesson is to assess the complete development environment: dependencies, endpoints, identities, repository permissions, cloud credentials and employee access lifecycle.

CrowdSec’s investigation shows that layered controls can constrain the consequences of a supply chain compromise, even when they do not prevent the initial intrusion.