CrowdSec Lost 170 Private Repositories in Nine Minutes to an Offboarding Gap

On 22 May 2026, between 05:52:29 and 06:01:33 UTC, someone working from an IP address in Toronto, Canada, used the GitHub account of a developer who had just left CrowdSec to copy about 170 of the French security company's private repositories. CrowdSec published that timeline in its own incident report on 18 September 2026 — the date the AI incident archive assigns this record — after an archive of its source code surfaced on the pwnforum cybercrime marketplace on 16 September. The account still worked because the company had deliberately left the developer's GitHub access open so they could finish some work. The laptop behind it had been infected eleven days earlier by the Mini Shai-Hulud credential-stealing worm that TeamPCP pushed through TanStack's npm packages. This account is drawn from the record filed on 18 September 2026, and the full documented incident set — each entry carrying its own severity, confidence grade, disputed flag and sources — sits in the Orca AI Incident Archive, where this one can be read next to the other supply-chain cases from the same year.

The theft did not stay limited to code. CrowdSec's report also disclosed the email addresses of 83 users, taken from an internal data-science monitoring list and mostly Gmail accounts, plus the first and last names, email addresses and investment context of 51 potential investors from 2020. Against roughly 150,000 users, 83 addresses is a small fraction; it is not zero. Chief executive Philippe Humeau reserved his personal apology for the investors: "Leaking your names and email addresses is an issue we'll discuss directly with you and the competent authorities, and for this I personally apologize."

What nine minutes actually took

The Git records GitHub handed back to CrowdSec start at 05:52:32.138 UTC with a fetch against one of the company's repositories, and the activity stops at 06:01:33. The archive's figure of about 170 private repositories comes from that Git data. In his write-up, Humeau describes the exposure as "limited to CrowdSecurity's source code, including 130+ public repositories and many private ones." DevOps.com, reporting the incident on 24 September, put the combined public and private count at about 300 repositories — a larger number than CrowdSec's own private-repository figure, and one the company's report does not state.

The contents were the ordinary furniture of a fast-moving SaaS company: the web console's source, deployment and automation scripts, and the data-science scripts and models behind its analytics. The most sensitive item CrowdSec names is the "consensus algorithm" that decides which IP addresses reach its blocklists. The algorithm's architecture was already public, but its diversity and detection thresholds were not, and those are now known. Humeau argues the thresholds are a moving target and that steering the consensus would still require a large, expensive fleet of servers; the company says it can adjust them and is watching for discrepancies.

Credentials were the part that could have gone much worse. "We were very close to clean," Humeau wrote. The one usable secret in the dump was an AWS Simple Notification Service token, scoped to publishing on a single topic. Someone tested it on 17 August 2026 from IP 23.234.84.102, calling GetCallerIdentity and ListTopics against both the dev and env topics, and got no further. Most other tokens and secrets in the code had been revoked or rotated before the leak. CrowdSec says its infrastructure and databases were not accessed and no code was altered in the open-source project, its private source or its build pipelines.

Why the account still worked

The offboarding failure is small and specific. By the time the developer left, CrowdSec had already removed their other access; the GitHub account was kept alive, Humeau wrote, because "we parted on good terms with our developer, and he wanted to finalize some work." The account was removed from the GitHub organisation on 25 May, three days after the repositories had already been copied.

CrowdSec could not see the theft at the time, and the reason is worth stating precisely. The OAuth token was not present in the organisation's audit log or in any current member's audit log, and by the time anyone went looking it no longer existed: it had been created, used and expired without leaving a trace the company could read. GitHub only retains Git activity on a rolling seven-day window for organisations not on an enterprise plan, as CrowdSec itself notes. The breakthrough came from GitHub's support team, which traced the token's full lifecycle and supplied the Git activity for the two-hour window around the copy. That is how the company arrived at a departed employee's account. The link back to TanStack came from the same exercise.

The leaked archive carried its own evidence. The .github/.git/config inside it recorded an origin URL of the form oauth2:gho_xxxxxxxxx@github.com, identifying the credential as a GitHub OAuth token and matching TeamPCP's documented methodology. CrowdSec says it checked developer machines for malicious packages and found none of the backdoored TanStack versions in its own repositories — a result it describes as inconclusive rather than exculpatory.

Who did it, and how firm the attribution is

CrowdSec attributes the download to "one of the founders of BreachForum and a member, diencracked", with the member's address given as diencracked@cock.li, operating from a Toronto IP with the machine's timezone set to UTC-4. The company adds its own hedge in the same sentence: "At least that's what the Git data shows." Dark Reading's report of 22 September carries the same attribution to the BreachForum founder and the diencracked handle.

The upstream campaign is better documented than the identities behind it. TanStack's packages were backdoored on 11 May 2026, when 84 malicious versions across 42 packages were published; The Hacker News records the compromise as CVE-2026-45321 and cites TanStack's own advisory for the credential-stealing payload. CrowdSec's timeline notes that on 22 May, the same day as the repository copy, TeamPCP — tracked by CrowdSec as UNC6780 — claimed responsibility for compromising repositories belonging to Mistral AI.

What is established, and what is not

Established: a copy of about 170 private repositories took place on 22 May 2026, in a nine-minute window, using a departed developer's still-valid GitHub account — a sequence reconstructed from GitHub's own Git activity records, not inferred. Also established by the company's own account: the exposure of 83 user email addresses and the details of 51 potential investors, the 25 May revocation, the probed SNS token, and the finding that no code was altered and no infrastructure or database was reached.

Not established: which poisoned package reached the laptop, and when. CrowdSec states plainly that it did not identify either. The company's repository scan was inconclusive, and its developer machines came back clean, which sits awkwardly with a laptop that was, on the company's own account, compromised. The gap is acknowledged rather than closed.

Not published: GitHub's side of the investigation. CrowdSec says GitHub's support team corroborated the TanStack origin, but The Hacker News notes that the company's report contains no findings from GitHub itself, and GitHub has not published its own account of the token's lifecycle.

Corroboration: Dark Reading, The Hacker News and DevOps.com each covered the incident within a week, and all three build on CrowdSec's report and TanStack's advisory rather than on an independent forensic examination of CrowdSec's systems. Dark Reading adds comment from outside practitioners, including Denis Calderone of Suzu Labs, who called the revocation lapse "day-one stuff". A Cloud Security Alliance research note dated 20 September repeats the sequence, but the document carries its own disclaimer that it was generated with AI assistance and has not undergone official CSA review — worth knowing before it is counted as a second independent finding. The archive grades the record confidence A, disputed false, real harm true.

The first statement, and the correction

CrowdSec's first public statement, on 17 September, said that "no client data, login/password, name, organization, or anything else was leaked, and CrowdSec doesn't store PII or client logs; the impact is limited to CrowdSec." It also floated a technical hypothesis: that an internal component had been backdoored to steal an API key capable of reading private code.

The fuller report a day later replaced that hypothesis with the departed employee's account, and disclosed the 83 addresses and the 51 investors. The Hacker News describes this as the earlier claim being corrected. CrowdSec's own framing is narrower: the 83 addresses came from a data-science monitoring list rather than customer records, and the investor details dated from 2020. Both descriptions can be true at once — the addresses were not customer accounts, and they were still personal data in a dump published on a crime forum. The company says it will notify the affected users and investors and report the leak to the authorities.

What changed afterwards

• Credentials and tokens found in the archive were rotated on the night of 16 September and through 17 September, with the remaining rotation completed the following morning.

• Endpoint detection and response is now deployed on the workstations and laptops of people who touch CrowdSec's codebase or infrastructure; the company names Aikido Security as the product. Humeau concedes it should have been in place earlier, and also concedes that a former employee's machine was unlikely to have been running it.

• The consensus-algorithm thresholds exposed in the leak are being adjusted, with tighter monitoring for statistical deviation across the blocklist network.

• The company has set itself a target of compressing the same response — inventory, rotation, forensics and disclosure — from 48 hours to under 24.

• Affected users and investors are being contacted directly, and the leak is being reported to the authorities, in the company's phrasing.

Why this sits in an AI incident archive

The AI involvement here is infrastructural, and it is worth being exact about what that means. Nothing in CrowdSec's account describes an AI system making a decision during the intrusion; the actor was a person or people using a stolen token. What makes the case an AI-industry incident is the blast radius. TanStack's libraries build the interfaces of a great deal of modern software, the worm that harvested the token is built to take cloud, SSH and model-provider credentials in one pass, and the material copied out of CrowdSec included data-science scripts and models rather than only application code.

The same campaign reached AI companies directly. CrowdSec's timeline records TeamPCP claiming Mistral AI repositories on 22 May, and The Hacker News reports that two OpenAI employee devices were affected, with unauthorised access to a limited set of internal code repositories. The archive records the CrowdSec case as the second downstream victim of the May TanStack compromise, after those OpenAI staff devices.

The distance between the copy and its discovery is the part that should travel. The repositories were taken on 22 May; CrowdSec learned of the leak on 16 September, when the Fuites Info team contacted the company about the pwnforum post — 117 days later, and not from its own monitoring. The mechanism that made the delay possible was not exotic: an account that outlived its purpose by three days, a token that left no trace in the logs the company could read, and developer laptops without endpoint detection. CrowdSec, a company that sells threat detection, had all three.