LiteLLM's postmortem: the breach started with a PR-filing agent holding the org owner's token
LiteLLM published the attack chain behind the compromised v1.107.0 release on October 23, and the root cause is the most on-thesis security story of the month. It was not a clever zero-day. It was an agent with a human's keys. Postmortem: https://docs.litellm.ai/blog/security-incident-oct-21-2026-attack-chain
The sequence, at the level that matters. On May 27, a config file committed to a public LiteLLM-Labs repo contained the master key for a deployment of LiteLLM's own agent platform, an experimental self-hosted cloud agent that files pull requests. The commit was force-pushed over but the key was never revoked. That agent platform had been set up with a GitHub CLI OAuth token belonging to the org owner. Not a service account, not scoped down. On October 10 the attacker used the leaked key to pull that token out and got owner access to every repo. The post notes that CLI tokens skip GitHub's sudo-mode 2FA re-check. From there the attacker collected more tokens, including two maintainers', and when a protected-branch merge failed review, used the owner token to switch the protection off and push the bad release. LiteLLM is now revoking every token on every internal and vendor system.
Railway's preliminary report on its own incident the same week adds the motive behind this wave of attacks on AI infrastructure: the campaign was after AI provider API keys to run distillation, and the actor had access to abliterated models and serious compute. https://blog.railway.com/p/preliminary-report-october-security-incident
Here is the uncomfortable lesson. Every coding-agent setup guide says to run gh auth login and let the agent open PRs. That is exactly what happened here, on a team that builds AI infrastructure for a living. An agent that can file PRs needs its own identity with its own narrow scope, so that when its secrets leak, which this shows they will, what leaks is a bot that can open draft PRs on one repo and nothing else. This week 1Password and Google both started selling credential custody for agents. LiteLLM just wrote the case study for why.
← Back to all articles
The sequence, at the level that matters. On May 27, a config file committed to a public LiteLLM-Labs repo contained the master key for a deployment of LiteLLM's own agent platform, an experimental self-hosted cloud agent that files pull requests. The commit was force-pushed over but the key was never revoked. That agent platform had been set up with a GitHub CLI OAuth token belonging to the org owner. Not a service account, not scoped down. On October 10 the attacker used the leaked key to pull that token out and got owner access to every repo. The post notes that CLI tokens skip GitHub's sudo-mode 2FA re-check. From there the attacker collected more tokens, including two maintainers', and when a protected-branch merge failed review, used the owner token to switch the protection off and push the bad release. LiteLLM is now revoking every token on every internal and vendor system.
Railway's preliminary report on its own incident the same week adds the motive behind this wave of attacks on AI infrastructure: the campaign was after AI provider API keys to run distillation, and the actor had access to abliterated models and serious compute. https://blog.railway.com/p/preliminary-report-october-security-incident
Here is the uncomfortable lesson. Every coding-agent setup guide says to run gh auth login and let the agent open PRs. That is exactly what happened here, on a team that builds AI infrastructure for a living. An agent that can file PRs needs its own identity with its own narrow scope, so that when its secrets leak, which this shows they will, what leaks is a bot that can open draft PRs on one repo and nothing else. This week 1Password and Google both started selling credential custody for agents. LiteLLM just wrote the case study for why.
Comments