Build1 publisher2 min readPublished
A backdoored TanStack dependency lifted the CI key that could read CrowdSec's private repositories
TanStack closed out its package compromise on May 15th, and CrowdSec learned 124 days later that the same incident had cost it a CI credential with read access to its private code. The notice came from an outside researcher.
The Engineer · Build desk
What happened
- CrowdSec disclosed on September 17th that an intruder accessed private GitHub repositories during a short window in May, holding code for its SaaS console, AWS cloud routines, connectors and automations.
- The company says it learned of the exposure on September 16th, when an outside researcher brought it to its attention, roughly four months after the suspected access.
- CrowdSec believes a compromised TanStack component in use internally during May extracted an API key belonging to a CI/CD component, and that the key could read its private codebase.
- TanStack's May 11th postmortem said an attacker exploited GitHub Actions, extracted a token from a runner process and published 84 malicious versions across 42 packages in a six-minute window.
- CrowdSec says no customer data, passwords, names, organizations, personally identifiable information or client logs were exposed, and that its open-source Security Engine was outside the incident's scope.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- constraint A key that can only read leaves the repositories it touches as it found them. The CI/CD controls behind a security vendor's own pitch had no anomalous write, job failure or config change to fire on.
- exposure Whoever held the key can read how CrowdSec's commercial side is wired, including internal service relationships and deployment practice, whether or not a single secret was stored in the trees.
- decision Every team that installed one of the affected packages in May has to decide whether TanStack's all-clear covered its own runner tokens. That all-clear did not cover the key CrowdSec lost.
- contradiction The 300-repository figure in circulation and CrowdSec's 132 public repositories describe the same estate, so the argument is about what counts as a sensitive system.
CrowdSec says the key taken from it belonged to a CI/CD component, authorized reading of private repositories, and that the exposure is limited to its own code [5][20]. A credential scoped to read is the hardest kind to catch in use, because reading a repository leaves it unchanged. The upstream half of the chain ran on a stolen token as well, and the malicious releases went out at about fourteen versions a minute [7].
CrowdSec dates the intrusion to a short window in May, and the four months of detection lag run from the suspected access to an outside researcher's notice [2][3].
TanStack deprecated the affected releases and issued an all-clear on May 15th [8]. CrowdSec learned it was affected 124 days after that [9]. An upstream fix tells a downstream team which versions to remove; which credentials were readable from a runner while a bad version was installed is a separate question. CrowdSec rotated the relevant tokens and credentials only after confirming the researcher's report [17].
CrowdSec says the roughly 300 figure in circulation is numerically accurate once its more than 130 intentionally public repositories are counted, and its public GitHub organization listed 132 repositories on September 17th [10][11]. That leaves about 168 private repositories in scope [12].
Those sit on the commercial side of CrowdSec's own boundary. The company gives the detection engine away and sells centralized management, integrations and threat intelligence [18]. Runtimewire's account argues that a repository-reading credential stays valuable even when secrets are kept elsewhere, because source trees carry configuration details, internal service relationships and clues about deployment practice [19].
For the finding of no usable credentials to hold across 168 repositories, the search has to have covered commit history and not just the current tree, since removing a secret from a file leaves it in earlier commits. The disclosure says the search has found none so far [14]. The TanStack path is CrowdSec's own reading of the evidence: runtimewire reports that the TanStack and Mistral records establish a campaign aimed at developer machines, build pipelines and their credentials, without independently verifying CrowdSec's access path [15]. Mistral said the malicious Python package harvested credentials from common locations on Linux systems, and that its investigation identified an affected developer device and no impact on its global infrastructure [16].
What to watch
- Whether CrowdSec publishes the scopes of the tokens its CI/CD component held, and what else that key could read.
- Whether other teams that installed one of the 42 affected packages in May report credential theft from their own runners.
- Whether the researcher who notified CrowdSec on September 16th publishes an account of how the exposure was found.