CrowdSec Source Code Leak Traced to TanStack npm Attack

The CrowdSec source code leak shows how a developer endpoint compromise can survive beyond an employee’s departure.

CrowdSec said an attacker copied about 170 private GitHub repositories on May 22, 2026. The attacker used a GitHub OAuth token associated with a developer who had recently left the company. CrowdSec had intentionally kept that developer’s GitHub membership active so they could finish work.

CrowdSec attributed the former employee’s compromise to the May 2026 TanStack npm supply-chain attack and linked the OAuth token used for the repository cloning to that former employee’s GitHub account. However, CrowdSec found no affected TanStack versions in its own repositories.

The incident connects three security problems: compromised software dependencies, credential theft from developer endpoints, and incomplete access revocation during offboarding.

How the TanStack npm Attack Led to the CrowdSec Source Code Leak

The upstream TanStack npm supply-chain attack occurred on May 11, 2026, when attackers published malicious versions of 42 @tanstack/* packages.

TanStack reported that attackers published 84 malicious versions across 42 @tanstack/* packages. The attack chained a pull_request_target workflow weakness, GitHub Actions cache poisoning, and runtime extraction of an OIDC token. That token enabled malicious packages to be published through TanStack’s legitimate trusted-publisher workflow.

Installing an affected version could execute an obfuscated JavaScript payload called router_init.js. The malware searched developer and CI environments for credentials including GitHub tokens, SSH private keys, cloud credentials, Kubernetes service-account tokens, and Vault tokens.

CrowdSec attributed the former employee’s endpoint compromise to the TanStack supply-chain attack, although its report does not identify the specific malicious package or installation event that compromised the machine.

Importantly, CrowdSec said its own repository history contained no affected TanStack package versions. This distinction indicates that CrowdSec’s own repositories and build pipeline were not the documented source of the malicious TanStack package exposure; CrowdSec instead attributed the former employee’s compromise to the TanStack campaign.

How a Lingering GitHub Account Kept the OAuth Token Useful

The compromised OAuth credential remained useful because the former employee still belonged to CrowdSec’s GitHub organization. GitHub programmatic credentials and their SSO authorizations require explicit consideration during offboarding, although their behavior depends on the organization’s GitHub identity and provisioning model.

CrowdSec said it had retained that access intentionally after the employee left so they could finish remaining work. Other access had already been revoked.

On May 22, activity associated with the account copied approximately 170 private repositories between 05:52:29 and 06:01:33 UTC, a window of roughly nine minutes. CrowdSec removed the account from its GitHub organization on May 25.

The company later found an OAuth token in the Git configuration contained within the leaked archive. GitHub support helped CrowdSec connect the activity to the departed employee’s account.

CrowdSec said the account was used solely for Git cloning. Its subsequent investigation found no commits or modifications to its code, infrastructure, or CI systems.

This makes the offboarding gap central to the incident. GitHub distinguishes identity-provider authentication from credentials used for programmatic access. With SAML SSO, organizations can manage SSO authorizations for supported credentials, including SSH keys, OAuth app user access tokens, GitHub App user access tokens, and personal access tokens. Fine-grained PATs follow different authorization behavior.

SCIM can automate GitHub deprovisioning when configured. However, the resulting actions depend on whether the organization uses personal GitHub accounts with organization-level SCIM or Enterprise Managed Users, where soft and hard deprovisioning have different effects. Therefore, security teams should explicitly review GitHub membership, SSO authorizations, OAuth applications, PATs, and SSH keys during offboarding.

Why the CrowdSec Source Code Leak Stayed Hidden Until September

The repository copying occurred in May, but CrowdSec did not learn about the leak until September.

An archive containing CrowdSec source code appeared on an online forum on September 16, 2026. CrowdSec began investigating that evening and published its completed incident analysis on September 18.

The archive contained more than source code. CrowdSec reported that it included email addresses belonging to 83 users. It also contained names, email addresses, and investment-related information for 51 potential investors from 2020.

CrowdSec said its infrastructure and databases had not been accessed. It also found no evidence that its open-source code, private source code, or build pipelines had been modified.

One usable AWS credential was present in the leaked code. CrowdSec said someone used it on August 17 to attempt GetCallerIdentity and ListTopics; the associated role was restricted to publishing to a single SNS topic, and CrowdSec reported no subsequent infrastructure activity from that credential.

CrowdSec rotated relevant credentials and tokens during its September 16 and 17 incident response.

What Security Teams Can Learn From CrowdSec’s OAuth Token Exposure

The incident demonstrates why developer endpoint security and identity lifecycle controls need to operate together.

• Revoke repository access as part of offboarding. Any intentional extension should have a defined owner, scope, and expiration. CrowdSec itself identified onboarding and deboarding procedures as an important lesson from the incident.
• Treat developer workstations as high-value endpoints. Package installation can execute code with access to credentials available to the developer environment. TanStack’s malicious packages specifically harvested GitHub, cloud, SSH, Kubernetes, Vault, and other credentials.
• Rotate credentials after suspected developer endpoint compromise. TanStack advised environments that installed affected versions to rotate credentials accessible from those hosts and review cloud audit logs.
• Reduce the lifetime and privilege of credentials. CrowdSec’s account retained GitHub access while most other permissions had already been revoked. That separation limited what the compromised identity could reach outside GitHub, according to the company’s investigation.

CrowdSec has also changed its endpoint security posture. The company said it did not enforce EDR on developer machines when the incident occurred. It now runs endpoint protection on workstations used by people interacting with its codebase or infrastructure.

How Hexnode Can Support Developer Endpoint and Identity Controls

The CrowdSec incident crosses two relevant defensive layers: the developer workstation where credential theft occurred and the identity lifecycle that left repository access active.

Investigate suspicious developer endpoint activity with Hexnode XDR

Hexnode XDR provides endpoint threat investigation and response capabilities for Windows and macOS devices. Security teams can use its threat-hunting capabilities to investigate suspicious activity on developer endpoints.

Hexnode XDR also provides response actions such as Isolate Device, Kill Process, and Quarantine File. Beyond endpoint containment, Hexnode can connect endpoint threat state with identity access decisions. Hexnode XDR can feed real-time threat signals into Hexnode IdP, allowing access to corporate applications to be revoked when an endpoint is flagged as a threat.

This threat-gated approach connects endpoint detection with the identity layer. However, these capabilities do not replace npm dependency remediation, GitHub credential revocation, or repository-specific access controls.

Use Hexnode UEM to maintain developer endpoint posture

Hexnode UEM can define device compliance requirements, identify managed endpoints that violate them, and manage required applications on supported devices. It also supports custom script execution across managed Windows, macOS, and Linux devices.

That capability can support administrative checks or remediation workflows across developer fleets. However, organizations should remediate affected npm dependencies through their established package-management and software-development workflows rather than treating UEM as a replacement for npm dependency management.

Tie identity access to managed-device posture

Hexnode IdP uses its Device Trust Engine to combine user identity with real-time device posture for access decisions. Its Continuous Zero Trust Enforcement extends verification beyond the initial login by continuously evaluating device posture and revoking access when risk conditions change.

That continuous verification matters when endpoint state changes during an active session. If a device falls out of compliance, Hexnode IdP can revoke application access rather than waiting for the user’s next authentication attempt.

Hexnode IdP also supports SCIM-based user lifecycle automation and federation with identity providers such as Microsoft Entra ID and Google Workspace. These capabilities connect device posture with broader identity and access workflows.

However, organizations must still manage GitHub-specific membership and credentials through the appropriate GitHub identity and access controls.

Featured resource

Why XDR Is Stronger With UEM

See how integrated endpoint management and threat response can help security teams close visibility and response gaps across managed devices.

Download the whitepaper

What Enterprises Should Do After the CrowdSec Source Code Leak

Organizations investigating exposure to malicious developer packages should address endpoint, identity, and developer-platform access separately.

Endpoint

• Identify developer endpoints and CI environments that installed affected package versions.
• Investigate those systems for the documented malware and related activity.
• Rotate credentials and secrets accessible from potentially compromised environments.
• Deploy endpoint protection consistently across systems with code or infrastructure access.

Identity

• Remove stale accounts and review offboarding exceptions.
• Give intentionally retained access a defined owner, scope, and expiration.
• Review identity-provider access, active sessions, and connected applications.

SaaS and GitHub repositories

• Review GitHub organization membership and repository permissions during offboarding.
• Review GitHub credentials and authorizations associated with departing or compromised users, including relevant OAuth app access, personal access tokens, SSH keys, and SSO authorizations.
• Revoke unnecessary SSO authorizations and credentials using the appropriate GitHub controls.
• Review source repositories for exposed secrets that could remain useful after repository theft.

For the TanStack incident specifically, organizations should follow the official TanStack and GitHub remediation guidance for affected packages and credentials.

The CrowdSec Incident Shows Why Offboarding Cannot Stop at Employment Status

The CrowdSec source code leak was not simply an npm compromise or a GitHub incident.

The reported chain crossed several boundaries: CrowdSec attributed a former employee’s endpoint compromise to the TanStack npm campaign, the associated OAuth token retained GitHub permissions, and an attacker used that token to copy approximately 170 private repositories. The theft remained undiscovered until the archive surfaced months later.

For enterprise security teams, that chain makes developer endpoints and identity lifecycle controls part of the same security problem.

Endpoint protection can help identify compromise. Access governance can limit what stolen credentials can reach. Neither replaces rapid secret rotation, repository-specific access controls, or complete offboarding.