Anatomy of a GitHub Supply-Chain Attack
Walk the October 2026 LiteLLM GitHub-identity compromise one step at a time. A single long-lived key in a public repo became org-owner access, then stolen maintainer tokens, a tampered release, and a rewritten history — every link in the chain was a control that could have broken it. For each step you see what happened, the control that would have stopped it, and a toggle to mark whether your org is exposed to that same class.
This is an educational reconstruction of the attack class. The factual steps are attributed to LiteLLM’s published root-cause analysis (RCA); no breach figures are invented here.
- What happened
Per LiteLLM’s published RCA, an Agent Platform master key had been committed into a public repository and left there. Because it was never rotated after exposure, a credential that should have had a lifetime of hours stayed valid for the attacker to find and use. A single long-lived secret in version control became the entire foothold.
Control that breaks the chain hereSecret scanning on every push and on the full history, plus automatic rotation on any exposure. A committed secret is treated as burned the moment it lands — detected, revoked, and reissued — not left live on the assumption nobody noticed.
Consolidated defenses
- Never commit secrets; enable push protection + full-history secret scanning, and rotate any exposed key immediately rather than monitoring it.
- Prefer short-lived, narrowly-scoped tokens and OIDC over long-lived stored secrets and durable owner OAuth grants.
- Keep org-owner privileges off everyday tooling, and require sensitive-action reauth that cannot be satisfied by replaying an existing token.
- Set GITHUB_TOKEN to read-only by default and grant per-job permissions explicitly.
- Require PR review of every new or changed workflow file before it can run.
- Pin third-party actions to a full commit SHA, not a mutable tag.
- Use environment protection rules with required human reviewers distinct from the build identity, and restrict secrets to protected branches.
- Add an egress allowlist on CI runners so a job cannot POST to an arbitrary external host.
- Stream GitHub audit and Actions logs to an append-only off-platform store, and alert on run-record or audit-log deletions.
- Forbid force-pushes and branch deletions on protected branches; require signed commits and review before merge.
- Verify release provenance/attestation so a build from an unexpected source fails even when approved by a genuine (but stolen) identity.
Why this matters
The LiteLLM incident is the modern supply-chain nightmare in miniature: no zero-day, no malware — just one long-lived secret that was never rotated, an owner token that skipped reauthentication, and a CI system that would run any workflow a write token pushed. Each link mapped to a control most teams already know about but had not turned on. Working the chain step by step shows exactly where your org would have broken it — and where it would not.
Educational — not affiliated with GitHub, GitLab, LiteLLM or any vendor named. Attack steps are attributed to LiteLLM’s published root-cause analysis; no breach figures are invented. Runs entirely in your browser: no accounts, no scans, nothing uploaded.
What this walkthrough shows
- A step-by-step walkthrough of the October 2026 LiteLLM GitHub-identity supply-chain compromise, as publicly reported — from a leaked master key to a force-pushed cover-up.
- Each step names the single control that would have broken the chain at that point: rotation, least-privilege tokens, protected branches, trusted publishing, and audit-log alerting.
- Built as an educational timeline, not an exploit recipe — there is nothing here that helps an attacker, only the defender-side lesson of each pivot.
- Runs entirely in your browser. No account, no data entered, no network calls.
Why this matters
The most damaging supply-chain incidents of 2026 did not turn on zero-days. They turned on stolen or mishandled identity — a credential with too much power, living too long, in the wrong place. The LiteLLM compromise is the clearest recent example: a leaked master key led, one ordinary GitHub capability at a time, to a tampered release and a covered-up history. Seeing the chain laid out makes the defensive lesson concrete — there is a specific, boring control at every step that would have stopped it.
This is an educational explainer that references a real, publicly reported incident for context. PlayCISO is not affiliated with LiteLLM or GitHub, and nothing here is attributed beyond what has been reported publicly.
Frequently asked questions
What happened in the LiteLLM GitHub compromise?
As publicly reported in October 2026, a long-lived master key was committed to a public repository and never rotated. An attacker used it to reach an org-owner gh CLI OAuth token, then ran throwaway CI workflows that exfiltrated maintainer secrets, published a release built from a fork source, deleted the workflow run records, and force-pushed to hide the change. No single step was a novel exploit — each was a normal GitHub capability reached with a stolen identity.
Was this a vulnerability in GitHub?
No. Every action in the chain — minting a token, running a workflow, cutting a release, deleting a run, force-pushing — is a legitimate GitHub feature. The failure was identity and configuration: a credential that should never have been in a repo, was never rotated, and carried org-owner power with nothing to re-challenge it. That is why the fixes are controls (rotation, least privilege, branch protection, trusted publishing, audit alerting), not a patch.
Which control would have stopped it earliest?
Not committing the key, or rotating it on a schedule, would have ended the chain before it began — secret scanning with push protection blocks the commit, and short-lived credentials shrink the window if one leaks. After that, least-privilege tokens (a fine-grained PAT or GitHub App instead of a broad gh CLI OAuth token on an owner account) would have contained the blast radius even with a stolen credential.
Is this tool safe to use / does it attack anything?
Yes, it is safe. It is a static, in-browser explainer of a publicly reported incident. It performs no attack, connects to nothing, and takes no input. Its only purpose is to teach the defensive control that breaks each link in the chain.
This tool is free and always will be. Would a Pro workspace — saved designs, team sharing and exports — be worth paying for?
Show me Pro →No account needed to use this tool — this just tells us whether Pro is worth building out.