The CrowdSec leak is a lesson in the OAuth token you forgot to revoke

Somewhere in your GitHub organization, a former employee still holds an active OAuth authorization for your private repositories. You just have not audited the list this year. And when the next npm supply-chain event fires, that grant is what walks out of a poisoned build and clones your source.

This is not hypothetical. DevOps.com reported on September 24 that CrowdSec, the French threat-intelligence outfit, had source code stolen from about 170 of its private GitHub repositories after an OAuth token tied to a former employee's GitHub account was scraped by attackers who had first compromised the TanStack npm packages. The attacker group calling itself TeamPCP cloned the archive in a window the report clocks at roughly nine minutes. The code eventually surfaced on a dark-web leak forum months later.

The chain, one step at a time

Walk the sequence end to end, because the interesting failure is not where you might expect.

Step one, per the report: in May, TeamPCP pushed malicious artifacts into TanStack's npm packages using a self-propagating worm the writeup labels "Mini Shai-Hulud." The worm's job was not to sabotage your build. Its job was to sit inside your build and rifle through the environment for credentials and tokens.

Step two: one of the developers whose install pulled a poisoned TanStack package happened to be a former CrowdSec employee. Their personal GitHub account still carried an OAuth authorization for CrowdSec's organization, with read access to private repositories. The worm scooped that token alongside everything else in reach.

Step three: attackers cloned. About 170 private repositories from a larger set of public and private ones, downloaded in a nine-minute burst that the report attributes to scripts rather than a human at a keyboard. CrowdSec revoked the former employee's access days later. The archive was already elsewhere, and it turned up on a leak forum in September.

The OAuth-app ledger nobody audits

Read that chain again. The npm worm is the loud, interesting part. The pivot into CrowdSec's private repositories was almost boring: it used an OAuth grant nobody had reviewed since the employee's exit interview.

An OAuth token issued to a personal GitHub account is a bearer credential. It does not know the employee left. It does not care that HR closed the ticket on their last working day. It sits in your organization's list of authorized OAuth apps until someone revokes it explicitly or the third-party app is uninstalled, and a repo scope covers every private repository the account had access to on the day the grant was signed.

This is the CI/CD security question that hides in plain sight. Every team drills SSO offboarding. Fewer teams script OAuth-app offboarding. Almost nobody drills a scenario where a third party's build is the compromise and the pivot vector is a token they issued three quarters earlier for a plugin nobody uses anymore.

What to actually check this week

Some of these are dull. Do them anyway.

1. Export the list of OAuth apps authorized in your GitHub organization, then cross-reference the user accounts against current employees. Every mismatch is a suspect.
2. Enforce OAuth-app approval at the organization level so an individual contributor cannot silently authorize a new tool against repo scope.
3. Where the tooling supports it, prefer GitHub Apps with fine-grained repository permissions over user-scoped OAuth apps. GitHub Apps live at the organization level and survive the employee, cleanly.
4. Rotate anything a poisoned CI or laptop build could have touched: .npmrc tokens, cached cloud credentials, SSH keys copied into agent workspaces, personal access tokens sitting in shell dotfiles.
5. Treat every ecosystem-scale npm compromise as a credential-rotation event for anyone whose laptop or pipeline installed that package family in the affected window. Not only the developer who noticed something odd. Everyone.

Where the industry is heading

Some ecosystems are sanding this problem down. GitHub's own push toward fine-grained personal access tokens and short-lived OIDC-brokered credentials in Actions targets the same shape: a token you cannot forget, because it expired ninety minutes after the workflow finished. GitLab and Bitbucket have moved along the same axis with workload-identity federation into the major cloud providers. The pattern is consistent across vendors. Replace long-lived bearer tokens with something the pipeline mints on demand and the identity provider revokes on its own timer.

None of that retires the OAuth-app grants sitting in your organization tonight. That surface predates the newer models. It is nobody's favourite thing to review, which is exactly why it is where the attackers went.

The kicker

Your offboarding checklist ends where your OAuth-app inventory begins. Go look at it. You will not like what you find.