LiteLLM Breach Root Cause: a Master Key Never Revoked
By @sharedot · · 6 pages
- Programming
- Supply Chain Security
- Litellm
LiteLLM says a master key leaked to a public GitHub repo in May 2026 was never revoked, letting an attacker hijack the release pipeline from inside.
How the breach actually started
The mystery of how attackers pushed malicious LiteLLM 1.107.0 now has a root cause. LiteLLM disclosed that on May 27, 2026, a configuration file committed to the public LiteLLM-Labs/lite-harness repository contained the master key for an Agent Platform deployment.
The team force-pushed over the commit and flagged the keys for revocation — but never revoked the master key.
On October 10, 2026, an attacker operating from IP 69.48.229.143 used it to reach the Agent Platform and extract a GitHub CLI OAuth token that was not scoped down and was tied to the organization owner's account, granting owner-level access to every repository.
Throwaway branches left almost no trace
According to Socket researcher Karlo Zanki, whose investigation The Hacker News shared, the attacker added malicious workflows at .github/workflows/cache.yml via commits to short-lived branches ci-tmp-a351cc and ci-tmp-4d8517, each created from a recent legitimate commit to look harmless.
The branches were created, used, and deleted within minutes, leaving almost nothing in ordinary repository history.
The October 12 run expanded harvesting to Anthropic, OpenAI, AWS Bedrock, Tavily, and GitGuardian credentials, plus Playwright storage state for Linear, PostgreSQL connection strings, and Redis authentication details — all exfiltrated to webhook.site endpoints.
A relaxed release rule opened the door
The most surprising detail is how the malicious release got approved. In normal operation, builds required an authorized engineer to trigger them and a special account locked to a physical office device to approve them.
LiteLLM says that restriction was relaxed earlier in the week for faster releases and backports, allowing any two engineers to trigger and approve — so the attacker used one stolen maintainer token to trigger the release from a lookalike repo, Berri-AI/litellm, and a second to approve it.
The maintainers note the attacker, already holding an owner token, could have removed the restriction entirely and likely avoided doing so to evade detection.
Stakes and what comes next
The malware's reach went beyond LiteLLM imports: per the Microsoft Security Research team, files bundled with 1.107.0 executed when Python started, installing a credential stealer targeting SSH files, Git and GitLab tokens, and package manager credentials for npm, PyPI, pip, Yarn, Maven, Gradle, Composer, RubyGems, and Cargo, plus a Unix backdoor fetching attacker commands hourly — posting data to litellm.dev › healthcheck, a domain registered October 13, 2026.
The stealer's startup files live outside the LiteLLM directory, so removing the package alone may not remove it.
LiteLLM's Oliver Jensen and Mateo Wang said the team is revoking every token tied to internal systems and vendor platforms, and acknowledged initial assumptions about token theft proved incomplete.