The important part is not only that an npm package was compromised. It is the complete chain: compromised dependency, infected developer workstation, stolen GitHub token, then private repository access. Each step may appear limited on its own; together they can expose a significant codebase.
The compromise chain
In its incident report, CrowdSec says a former employee was still a member of the GitHub organization to finish remaining work. Their workstation received a compromised package from the TanStack ecosystem in the context of the Shai-Hulud campaign.
According to CrowdSec, the malware enabled attackers to obtain a valid GitHub token. On May 22, 2026, that token was then used to download content from roughly 170 private repositories.
CrowdSec says the observed access was effectively read-only: it found no changes to source code, build pipelines, databases or infrastructure. The exposure mainly involved private source code.
The real issue: offboarding cannot stay informal
The affected collaborator's GitHub access had not been revoked immediately after departure because the relationship ended on good terms and some work still needed to be completed. That is understandable operationally, but risky technically.
An account outside normal day-to-day operations may receive less attention: a less-supervised workstation, older sessions, forgotten tokens or permissions retained longer than necessary.
A departure should not create a grey zone
If someone needs to continue working after a contract or role ends, creating a new temporary, scoped and time-limited access path is safer than keeping historical permissions alive.
A GitHub token is access, not just a secret
Personal, OAuth and application tokens should be managed like technical identities: known owner, defined scope, expiry date, last use and reachable resources.
During an incident, the question is not only “which secret leaked?” but also “which repositories and organizations could that credential actually reach?”
This visibility matters even more as modern development stacks multiply credentials across CLIs, IDEs, AI agents, OAuth apps, automation, GitHub Apps and CI/CD pipelines.
Controls worth keeping
- Revoke access on the departure date, then create a separate temporary access if further work is required.
- Inventory credentials regularly: PATs, OAuth tokens, SSH keys, GitHub Apps and service accounts.
- Shorten token lifetimes and avoid credentials without expiry.
- Limit scopes and repository access to what is strictly required.
- Review last-used information to identify dormant or unexpected access.
- Treat developer workstations as security boundaries, because they often combine code, tokens and CI/CD access.
- Prepare forensic visibility with audit logs and the ability to tie a credential back to its owner.
Why credential inventory is becoming strategic
GitHub announced credential inventory exports for GitHub Enterprise Cloud on September 21, 2026. They can include SSH keys, PATs, OAuth tokens and GitHub App credentials with ownership, permissions, dates and target resources.
The feature is Enterprise-specific, but the principle applies to every team: being able to answer “who can still access what?” quickly is a security capability in its own right.
Supply-chain security does not end at the compromised package
The CrowdSec incident shows that a dependency compromise does not need to reach production directly to matter. A developer workstation can bridge an external dependency and sensitive internal resources.
The stronger defense therefore combines supply-chain controls with access hygiene: monitored dependencies, short-lived scoped tokens, prompt revocation, continuous inventory and explicit offboarding rules.
Sources
- CrowdSec — TanStack Supply Chain Attack Analysis, September 18, 2026
- GitHub Changelog — Credential inventory exports, September 21, 2026
Published September 22, 2026. Incident facts are summarized from CrowdSec's public post-incident report.