The root cause traces back to CVE-2026-45321, the compromise of the TanStack Router and Start npm ecosystem. On 11 May, an attacker chained an unsafe pull_request_target workflow, GitHub Actions cache poisoning and runtime extraction of an OpenID Connect token to publish 84 malicious releases across 42 @tanstack packages, each carrying an obfuscated install-time payload built to harvest GitHub and npm tokens, cloud credentials, and SSH keys from any machine that installed them - reporting on the incident, Cybersecurity News and others tracked it as part of the wider "Shai-Hulud" npm worm campaign. One of the machines that installed a poisoned package belonged to a developer who had already left CrowdSec.
"We parted on good terms" is not an access control
CrowdSec's own account of the decision, published in its incident analysis, is unusually direct: "We kept them alive because we parted on good terms with our developer, and he wanted to finalize some work." That access stayed live through 11 May, when the developer's machine picked up the poisoned TanStack package, and on into the early hours of 22 May, when the attacker used the harvested GitHub OAuth token to download roughly 170 private CrowdSec repositories in a nine-minute window between 05:52 and 06:01 UTC. CrowdSec revoked the account on 25 May - three days after the copying had already happened, and with no idea yet that it had.
What sat in the repositories the attacker took
According to CrowdSec's report, the stolen material included the source for its web console, its data science scripts and models, deployment and automation tooling, and - most sensitive for a company whose entire product is a shared threat-intelligence blocklist - the consensus algorithm and previously undisclosed scoring thresholds it uses to decide when an IP address gets added to that blocklist. Also exposed: the email addresses of 83 CrowdSec users, and the names and email addresses of 51 people who were potential investors back in 2020. CrowdSec says its infrastructure and databases were never reached, no code in the open-source project or build pipeline was altered, and the one credential the attacker did test - an AWS SNS token, checked on 17 August - turned out to have permissions limited to a single notification topic and nothing more.
Four months between the theft and CrowdSec finding out
Nobody at CrowdSec knew any of this had happened until 16 September, when the stolen code turned up on a cybercrime forum - four months after the actual copying took place. The Hacker News's coverage of the disclosure lays out just how compressed CrowdSec's response was once that happened: crisis response began at 17:45 that day, an initial public statement went out by noon the next day, and a full forensic report followed on 18 September. That speed matters, but it doesn't change the shape of the underlying failure - a four-month gap between a breach and its discovery is exactly the kind of window that turns a contained credential-theft incident into a genuine unknown, because nobody can be certain what else happened in a period nobody was watching.
- Revoke a departing employee's access on their last working day, full stop - a documented handover exception for "finishing some work" is a policy decision that needs its own sign-off and its own expiry date, not an informal courtesy.
- Treat any credential belonging to a former employee as higher-risk than an active employee's, not lower-risk - there's no one left routinely using it who would notice unusual activity on it.
- Run credential and token usage monitoring that would catch a nine-minute burst of unusual repository downloads regardless of whose account triggered it, rather than relying on the account holder to notice.
- Assume any developer machine that installed a since-revealed malicious package may have leaked every credential that machine had cached, and rotate accordingly - not just the credential the package was specifically designed to steal.
- Build incident response runbooks around the assumption that a breach discovered today may have happened months ago, and scope the investigation to the full period since the credential was last known-good, not just since detection.
A security vendor's own product is only as credible as the access hygiene behind it, and CrowdSec's postmortem is candid about that gap in a way plenty of breached companies aren't. If your organisation's offboarding process has ever made a "just this once" exception for a departing developer, this is the week to check whether that exception ever got closed. Email sales@halfteck.com if you'd like a second pair of eyes on it.