CrowdSec Traces Theft of 300 GitHub Repositories to Malicious TanStack Dependency

Attackers reached private code through a software dependency

French cybersecurity company CrowdSec has confirmed that attackers exfiltrated source code from approximately 300 of its GitHub repositories, including around 170 private repositories.

The company learned last week that the theft had occurred during May 2026. Its investigation connected the intrusion to the TanStack software supply-chain campaign attributed to TeamPCP, which distributed 84 malicious artifacts through 42 TanStack packages.

CrowdSec believes malware delivered through a compromised package obtained an API key capable of reading its private codebase. That credential apparently allowed the attackers to copy both public and non-public repositories without requiring a separately identified breach of CrowdSec’s core production infrastructure.

The stolen private code covered CrowdSec’s SaaS console, some AWS Cloud routines, connectors, and automation components. According to CrowdSec’s account of the investigation, investigators have not found evidence that customer credentials or other customer-related information were exposed.

For now, the company assesses the direct impact as internal.

The suspected path from package installation to GitHub access

CrowdSec used a TanStack package during May 2026, when the malicious artifacts were active. The company’s working theory is that code executed from the compromised dependency captured an API key from its development environment.

An API key with repository-reading permissions can provide a supply-chain attacker with a direct route into proprietary code. Instead of exploiting each repository separately, the attacker can use the trusted credential to enumerate and download every project available to that identity.

That appears to explain the scale of the theft: roughly 300 repositories were affected, more than half of them private. The available information does not establish whether every repository was downloaded in full or whether the attackers selected particular files from some projects.

Several technical details remain undisclosed. CrowdSec has not identified the exact TanStack package or package version it used, nor has it published the API key’s precise permissions, relevant GitHub audit events, or other indicators of compromise. No malicious filenames, hashes, domains, or network addresses have been released.

The company described the likely exposure period as a short window in May 2026. Once it identified the risk, it rotated all tokens and credentials that might have been affected.

What the stolen repositories contained

The private repositories included code supporting four significant areas of CrowdSec’s operations:

• The CrowdSec SaaS console;
• Certain AWS Cloud routines;
• Connectors used to link systems or services;
• Internal automation functionality.

This is not the same as a confirmed disclosure of customer databases, passwords, access tokens, or production data. CrowdSec searched the affected material and its environment for credentials, API keys, tokens, and other secrets that could facilitate lateral movement. It said that effort had not identified such material so far.

The distinction matters, but source-code exposure still creates security work. Attackers can examine proprietary code for implementation weaknesses, undocumented interfaces, cloud assumptions, internal naming conventions, and logic that may support later intrusion attempts. Even when secrets are not deliberately embedded, configuration fragments, test fixtures, commit history, and automation scripts can reveal operational details.

CrowdSec argues that the copied code cannot readily operate outside its original environment. Reproducing the company’s services would require its network, data, tools, and supporting infrastructure. The vendor also said the SaaS code undergoes regular audits and that much of the leaked material had changed substantially during the previous four months.

Those factors can reduce immediate exploitability. They do not make the theft irrelevant.

No customer compromise has been identified

CrowdSec has found no evidence that the attackers obtained customer credentials or other customer-related information. It also has not reported that TeamPCP used the stolen code to access customer deployments, cloud resources, or the production SaaS platform.

The current assessment is therefore narrower than the repository count might initially suggest: CrowdSec’s intellectual property was exposed, but a customer data breach has not been established.

That conclusion may change if later analysis uncovers credentials that escaped the initial search or detects suspicious activity linked to knowledge contained in the code. Source-code investigations can take time because secrets may exist in previous commits, archived branches, generated files, or build logs rather than the current version of a project.

CrowdSec said it will continue monitoring for abnormal behavior. The company has not disclosed evidence of follow-on exploitation, extortion, public release of the repositories, or attempts to weaponize vulnerabilities found in the stolen code.

No CVE identifier, CVSS score, or formal severity rating applies to the incident as described. There is also no associated entry in CISA’s Known Exploited Vulnerabilities catalog. This is a credential-enabled supply-chain breach, not a disclosed vulnerability with a vendor patch and affected-version table.

Response focused on credentials and lateral-movement risk

CrowdSec’s first containment measure was rotating all potentially affected tokens and credentials. That action was necessary because the suspected initial access involved an API key rather than a software flaw that could be resolved solely by installing an update.

The company also searched for sensitive material that might allow the attacker to progress beyond repository access. Investigators reviewed the compromised repositories and examined the code supporting the SaaS console, AWS routines, connectors, and automations.

Its continuing response includes:

1. Monitoring for unusual activity associated with the affected identities and environments;
2. Reviewing private repositories for embedded or historical secrets;
3. Assessing whether exposed code reveals useful paths into cloud or production systems;
4. Maintaining source-code audits for the SaaS platform;
5. Investigating possible lateral movement from the compromised development credential.

CrowdSec has not reported finding lateral movement. However, the absence of detected credentials inside current source files does not by itself exclude exposure through repository history or related development systems.

What TanStack users and development teams should examine

Organizations that used TanStack packages during the May 2026 exploitation window should verify package provenance and inspect dependency, lockfile, build, and installation histories. Because the compromised package names and versions relevant to CrowdSec have not been disclosed, defenders cannot rely on a CrowdSec-specific package indicator.

Teams should identify credentials available to package installation scripts, build runners, developer workstations, and continuous-integration jobs. Any token exposed to those environments should be evaluated according to its permissions and rotated where compromise cannot be ruled out.

GitHub administrators should review repository access for unusual enumeration, cloning, archive downloads, or API activity involving development and automation identities. Cloud teams should also examine whether repository code or build systems contained credentials capable of reaching AWS resources or other infrastructure.

For organizations integrating with CrowdSec, there is currently no evidence that the vendor’s customer credentials or customer information were stolen. Customers should not treat the incident as proof that their own environments were breached. They should nevertheless investigate unexpected authentication or API activity if their deployments shared credentials with affected development workflows.

The incident demonstrates the reach of a malicious dependency: one compromised package can inherit the access available to the environment that executes it. In CrowdSec’s case, the suspected result was an API key and access to hundreds of repositories. The remaining question is whether the stolen code can help TeamPCP—or another party that receives it—move beyond intellectual-property theft.