The Hacker News reported on September 19 that CrowdSec said about 170 private GitHub repositories were copied in May using a GitHub OAuth token tied to an employee who had recently left the company. CrowdSec connected the access to the earlier TanStack npm attack, where malicious package versions harvested developer credentials from affected machines.
CrowdSec's own September 18 analysis said the account was used to clone repositories, not to change code or access its infrastructure or databases. The company also said it rotated exposed credentials, reviewed its logs, and later traced the activity with help from GitHub. That makes this less a story about one vendor's mistake and more a useful stress test for how businesses manage developer access after people, devices, and packages move on.
The business decision is access ownership
Many New Jersey businesses do not think of GitHub, npm, OAuth tokens, and developer laptops as boardroom issues. They can become one quickly when a software vendor, contractor, internal developer, or MSP has access to source code, deployment scripts, cloud credentials, customer portals, or automation tools.
The GitHub token leak lesson is simple: offboarding is not finished when email is disabled and a laptop is returned. Developer access often lives in code-hosting organizations, package managers, OAuth app grants, CI/CD systems, SSH keys, cloud roles, password vaults, test environments, and old contractor accounts. If those pieces are not reviewed together, an account that looks mostly closed can still open a door.
Questions for the team managing code access
- Former users: Which departed employees, contractors, vendors, and MSP staff still have access to GitHub, GitLab, Bitbucket, package registries, or deployment tools?
- OAuth grants: Which OAuth apps and personal tokens can read repositories, create workflows, or access organization data?
- Developer devices: Are laptops that touch code protected against malicious packages, browser token theft, and credential-stealing malware?
- Package exposure: Did any internal project install affected TanStack npm packages or other compromised dependencies during the relevant window?
- Logs: Can the provider show repository clone, token, and organization-membership logs for the period in question?
- Rotation: Which API keys, SSH keys, cloud credentials, webhooks, and service tokens were rotated after the incident review?
- Exception handling: If access is kept open after someone leaves, who approved it, why was it needed, and when does it expire?
A practical next step
Owners do not need to personally audit every repository permission. They do need a clear answer from the person responsible for technology operations: who owns developer offboarding, how quickly access is removed, how OAuth token review is handled, and how the business verifies that no leftover token can still read private code.
For organizations that use custom software, web agencies, SaaS integrations, or outsourced IT, this is also a vendor accountability question. A provider that says access has been removed should be able to show the checklist, the systems reviewed, and the evidence behind the answer.
The headline may involve CrowdSec, TanStack, npm, and GitHub. The owner-level lesson is broader: code access is business access. When a software supply chain attack reaches a developer machine, the cleanup has to include people, devices, tokens, packages, and proof.
Sources and further reading
