Security Analysis | September 19, 2026

The recent CrowdSec source code leak highlights how a software supply chain attack can escalate into a serious security incident when compromised developer endpoints, stolen authentication tokens, and insufficient access lifecycle controls intersect.

According to CrowdSec's incident report, an attacker obtained access to approximately 170 private GitHub repositories using credentials associated with a former employee whose laptop had been compromised during the TanStack npm supply chain attack.

The attack demonstrates that even cybersecurity companies with established security practices can be exposed through trusted software dependencies and development workflows.

More importantly, it provides valuable lessons about what organisations must do to prevent similar incidents.

1. What Happened at CrowdSec?

The incident originated from the TanStack npm supply chain compromise in May 2026.

On May 11, attackers distributed 84 malicious package versions across 42 TanStack npm packages. These compromised packages contained credential-stealing malware capable of targeting sensitive information on developer workstations.

CrowdSec subsequently determined that a former employee's laptop had been compromised through the attack.

Although the employee had already left the company, his GitHub access had been retained temporarily to allow him to complete outstanding work.

On May 22, the attacker used a GitHub OAuth token associated with that account to clone private repositories belonging to CrowdSec.

The account was removed from CrowdSec's GitHub organisation on May 25, but the repositories had already been copied.

The stolen source code appeared on an online forum on September 16, nearly four months after the original theft.

CrowdSec's subsequent investigation linked the exposure to the TanStack compromise.

The company reported that the attack did not result in unauthorised changes to its source code, build pipelines, infrastructure, or databases.

However, the stolen repositories contained proprietary software components, including its SaaS console, data science code, automation scripts, and the consensus algorithm used in its threat intelligence operations.

CrowdSec also acknowledged the exposure of 83 users' email addresses and information relating to 51 prospective investors.

These findings demonstrate that source code exposure can have consequences beyond intellectual property theft, potentially revealing sensitive business information, internal implementation details, and security-relevant application logic.

2. Understanding the Attack Chain

The incident involved several interconnected security failures and attack techniques.

Stage 1: Software supply chain compromise

Attackers compromised TanStack's npm publishing process and introduced malicious code into packages that developers could install as legitimate dependencies.

The original TanStack attack exploited weaknesses in GitHub Actions workflows, including CI cache poisoning and theft of a publishing token.

This enabled attackers to distribute malicious packages through the legitimate npm ecosystem.

Stage 2: Developer workstation compromise

The malicious package reached a former CrowdSec employee's laptop.

Compromised packages can execute malicious code during installation or other build operations, potentially exposing credentials stored or accessible on the development machine.

In this case, the subsequent investigation connected the employee's compromised laptop to the stolen GitHub token.

Stage 3: Abuse of retained access

The employee's GitHub account remained authorised after departure.

The attacker was therefore able to use a stolen OAuth token to access repositories that the account was still permitted to read.

Stage 4: Repository exfiltration

The attacker cloned CrowdSec's private repositories on May 22.

A token that provides legitimate repository access can be abused to retrieve substantial amounts of source code without exploiting a vulnerability in GitHub itself.

Stage 5: Delayed discovery

The stolen repositories were publicly disclosed in September, months after the initial exfiltration.

CrowdSec's investigation established the timeline after receiving information about the leaked archive and working with GitHub to trace the token.

The incident illustrates how a supply chain compromise can develop into a secondary breach long after the original malicious package has been removed.

3. What Companies Should Do to Prevent Similar Incidents

The CrowdSec incident provides an opportunity for organisations to review security controls across the entire software development lifecycle.

The following measures directly address the weaknesses and attack paths demonstrated by this incident.

A. Protect Developer Workstations with Endpoint Detection and Response

Developer laptops should be treated as high-value security assets.

Unlike ordinary employee endpoints, developer systems frequently have access to source code, package managers, Git repositories, cloud infrastructure, and sensitive authentication material.

Organisations should deploy endpoint detection and response (EDR) capabilities on all systems used for software development.

These controls should monitor:

  • Unexpected processes launched by package managers such as npm.
  • Attempts to access SSH keys, GitHub credentials, and cloud authentication files.
  • Suspicious execution of installation scripts.
  • Unusual outbound connections following dependency installation.
  • Attempts to archive or transfer large volumes of source code.
  • Unauthorised access to sensitive local directories.

Companies should also establish alerting for unusual process behaviour, such as npm invoking a shell that subsequently accesses credentials or initiates unexpected network connections.

Prevention objective: Detect and contain malicious dependency execution before stolen credentials can be used for broader compromise.

Endpoint protection does not guarantee that every malicious package will be detected, but it provides a critical additional security layer beyond dependency scanning.

B. Implement Immediate Employee Offboarding and Access Revocation

One of the most important lessons from this incident concerns the former employee's retained GitHub access.

Although the access was maintained for a legitimate business reason, it created an opportunity for attackers after the employee's laptop was compromised.

Organisations should implement a formal offboarding process that immediately revokes access to:

  • GitHub, GitLab, and other source code repositories.
  • Cloud platforms and infrastructure.
  • VPN and remote access systems.
  • CI/CD platforms and deployment systems.
  • Corporate applications and identity providers.
  • Personal access tokens, OAuth authorisations, SSH keys, and other relevant credentials.

If an employee must complete unfinished work after departure, access should be explicitly approved, limited to the required repositories, restricted to a short duration, and monitored.

Preferably, the remaining work should be transferred to an active employee instead of retaining the departing employee's original access.

Where technically supported, organisations should automatically revoke sessions, tokens, and credentials associated with a departing employee.

Prevention objective: Ensure that a compromised former employee account cannot become an entry point into corporate systems.

C. Adopt a Zero-Trust Approach to GitHub and Repository Access

Possession of a valid authentication token should not automatically grant unrestricted access to an organisation's entire codebase.

Companies should review repository permissions and grant developers access only to the projects required for their responsibilities.

Recommended controls include:

  • Enforcing phishing-resistant multi-factor authentication for interactive access.
  • Using short-lived, narrowly scoped credentials wherever possible.
  • Limiting OAuth applications and requiring administrative approval.
  • Restricting access to sensitive repositories.
  • Regularly reviewing repository permissions and inactive accounts.
  • Monitoring unusual repository cloning and bulk downloads.
  • Removing unnecessary personal access tokens and SSH keys.

Organisations should recognise that MFA alone cannot prevent the abuse of an already stolen and valid access token.

Additional controls must limit the token's permissions, lifetime, and potential misuse.

Prevention objective: Reduce the amount of source code an attacker can obtain if a developer's credentials are compromised.

D. Strengthen npm Dependency and Software Supply Chain Security

The original compromise exploited the trust placed in software packages distributed through npm.

Companies should establish controls that prevent newly published or unauthorised dependencies from entering production and development environments without appropriate scrutiny.

Recommended measures include:

1. Enforce dependency lockfiles

Use package lockfiles and reproducible installation commands, such as npm ci, to prevent unexpected dependency resolution.

However, lockfiles are not sufficient if an attacker compromises a package version that the organisation subsequently approves and locks.

2. Introduce a package release waiting period

Configure a minimum package release age where supported by the package manager or an internal registry.

This delays the adoption of newly published packages and provides additional time for malicious releases to be identified.

A waiting period reduces exposure but cannot guarantee protection against attacks that remain undetected.

3. Use an approved internal package registry

Route dependency installations through a controlled repository that can enforce package approval, version restrictions, malware scanning, and security policies.

4. Analyse package behaviour

Inspect high-risk dependencies and installation scripts for suspicious behaviour, including credential access and unexpected network communication.

5. Generate and maintain an SBOM

Maintain a Software Bill of Materials to identify which applications and developer environments depend on potentially compromised packages.

6. Verify package integrity and provenance

Validate package hashes and available provenance information.

However, provenance alone does not prove that a package is safe, particularly when the legitimate publishing pipeline itself has been compromised.

Prevention objective: Prevent malicious open-source dependencies from executing on trusted development systems.

E. Secure CI/CD Pipelines Against Cache Poisoning

The TanStack compromise demonstrates how attackers can abuse development automation even without stealing a maintainer's credentials.

The attackers exploited a GitHub Actions workflow that allowed untrusted pull-request code to influence a shared cache subsequently consumed by a privileged release workflow.

Organisations should:

  • Avoid executing untrusted pull-request code with privileged workflow permissions.
  • Review potentially dangerous uses of pull_request_target.
  • Isolate CI caches belonging to untrusted contributions.
  • Prevent untrusted jobs from modifying artifacts used by release pipelines.
  • Separate testing workflows from package publishing workflows.
  • Restrict CI/CD tokens to the minimum permissions required.
  • Pin third-party GitHub Actions to verified commit hashes.
  • Use isolated, short-lived build environments.

Security teams should specifically investigate whether untrusted code can influence a privileged workflow indirectly through caches, artifacts, shared storage, or generated files.

Prevention objective: Prevent attackers from converting an ordinary external contribution into control over an organisation's software release process.

F. Protect Developer Credentials and Secrets

Developer credentials should not be permanently accessible to every process running on a workstation.

Organisations should avoid storing long-lived authentication tokens in plaintext files, scripts, or environment configurations where feasible.

Recommended practices include centralised secrets management, short-lived authentication, tightly scoped access permissions, and automatic credential rotation.

For high-value repositories, consider separating sensitive access into hardened development environments.

Where practical, development containers or isolated build environments should not contain host credentials or unrestricted access to the host filesystem.

Prevention objective: Limit the credentials accessible to malicious code even if a software dependency executes.

G. Monitor Source Code Access and Repository Exfiltration

One of the most significant challenges in incidents like CrowdSec's is distinguishing legitimate development activity from malicious repository access using valid credentials.

Security teams should monitor GitHub and other source control audit events for indicators such as:

  • Large-scale cloning of private repositories.
  • Access to numerous unrelated repositories within a short period.
  • Repository activity from unexpected locations or devices.
  • Unusual activity involving accounts scheduled for deactivation.
  • Newly authorised OAuth applications.
  • Unexpected token creation or permission changes.

These events should be correlated with endpoint telemetry, identity logs, and network activity.

Where possible, unusual bulk access should trigger investigation or automated containment.

Prevention objective: Identify suspicious repository access before attackers can exfiltrate an organisation's entire private codebase.

4. What Should Companies Do If They Have Already Installed a Compromised npm Package?

Organisations that identify potentially compromised TanStack package versions should treat affected development machines as possible credential exposure points.

Immediate actions should include:

  1. Identify systems that installed or executed the malicious package versions using dependency inventories, lockfiles, package manager logs, and endpoint telemetry.

  2. Isolate potentially compromised endpoints while preserving relevant forensic evidence.

  3. Revoke and rotate potentially exposed GitHub tokens, SSH keys, npm publishing credentials, cloud credentials, and other secrets.

  4. Review source control audit logs for unauthorised repository access, cloning, or permission changes.

  5. Investigate whether the malicious package accessed sensitive files, credentials, or network resources.

  6. Rebuild affected developer systems from trusted images when compromise cannot be confidently ruled out.

  7. Validate the integrity of source code, build pipelines, published packages, and release artifacts.

  8. Investigate potential data exposure and fulfil applicable notification obligations.

Simply removing the malicious npm package is insufficient if the attacker has already stolen valid credentials.

Credential revocation, exposure assessment, and endpoint investigation must be part of the remediation process.

5. The Bigger Lesson for Cybersecurity Companies

The CrowdSec incident is particularly relevant because the affected organisation operates in the cybersecurity industry.

Security vendors routinely protect customers against external threats, but their own development infrastructure also represents a valuable attack target.

Source code can reveal application architecture, proprietary algorithms, internal workflows, and implementation details that attackers may study for future exploitation.

In CrowdSec's case, the exposed material included details of its consensus algorithm and associated thresholds.

CrowdSec stated that it had not identified evidence that its blocklist could be poisoned as a result of the leak. Nevertheless, exposing previously private implementation details can provide attackers with information that warrants further security review.

For companies developing firewalls, intrusion prevention systems, endpoint security products, and other cybersecurity technologies, the implications are especially important.

A compromised development environment can potentially expose intellectual property, provide access to sensitive code, or become a pathway into software distribution infrastructure.

This makes secure development environments, strict access controls, supply chain monitoring, and release integrity essential components of product security.

Security companies must protect not only their customers' infrastructure but also the systems used to build and maintain the products their customers trust.

Conclusion

The CrowdSec incident demonstrates that a successful software supply chain attack does not necessarily end when the malicious package is removed.

Stolen credentials may remain valid, former employee accounts may retain access, and attackers may exploit these opportunities days or weeks after the initial compromise.

The incident also highlights the limitations of relying on any single security measure.

Dependency scanning cannot replace endpoint protection. MFA cannot fully prevent stolen-token abuse. Employee offboarding cannot be effective without complete credential revocation. And source code repositories cannot remain secure without access monitoring and least-privilege enforcement.

Organisations should adopt a layered approach that combines dependency security, hardened development environments, endpoint monitoring, secure CI/CD workflows, credential protection, and continuous repository access auditing.

The central lesson: Protecting the software supply chain requires protecting the entire path from third-party dependencies to developer workstations, authentication tokens, source code repositories, and production release systems. A weakness at any point in this chain can undermine the security of everything connected to it.

An attacker copied about 170 of CrowdSec's private GitHub repositories on May 22 using the account of an employee who had just left, CrowdSec said on September 18. The French security company had kept his GitHub access open. CrowdSec says his laptop was compromised in May's supply chain attack on TanStack, in which malicious versions of TanStack's npm packages stole credentials from

Source: CrowdSec Says TanStack npm Attack Led to Copy of 170 Private GitHub Repositories via The Hacker News — published 19 Sep 2026.