Five days of coverage of the LiteLLM compromise have told two different stories. The first reports, on October 21 and 22, were about a poisoned Python package that stole credentials from anyone who installed it. By October 26 the story had become one about a key that leaked in May and was never revoked, and about what a single GitHub token can do once an attacker holds it.
LiteLLM, the open-source gateway that gives developers one interface to OpenAI, Anthropic, Google Gemini and other model providers, shipped a malicious version 1.107.0 to PyPI and its container registries on October 21 after its release pipeline was compromised. The Register, Help Net Security, The Hacker News and The Record all covered it that week. Read in order, they track how the company’s own explanation changed, including one early detail LiteLLM has since withdrawn.
What the accounts agree on
The facts of the release are settled and every account carries them. LiteLLM’s incident post says the malicious package was live on PyPI from 11:39 to 13:23 UTC, and that the Docker images tagged v1.107.0, latest, main-latest and main-stable served the bad build from 11:46 to 14:20 UTC. The most recent safe version is 1.106.2. Help Net Security, citing Socket, and The Record, citing Microsoft, both report that the malicious code ran whenever Python started on an affected machine, even if the program never used LiteLLM.
The accounts also agree on what anyone who installed it has to do. LiteLLM says that if 1.107.0 was ever installed on a host with outbound internet, the owner should assume the exfiltration succeeded and rotate everything the host could reach, from cloud roles to every provider key stored in the proxy database.
Where they differ
The Register wrote first, on the evening of October 21, and wrote for the threat hunter. Its account is built around indicators: the files to search for, the hyphenated Berri-AI organization the build came from, and a line from Socket’s researchers: “Teams using 1.107.0 should stop deploying it and investigate environments where Python ran after installation, including proxy containers and CI runners.” It said it was too early to tell the scale. How the attacker reached the release pipeline is absent from the story, because LiteLLM had not yet said.
Help Net Security, a day later, carried an explanation, and it was LiteLLM’s first one. The company had found an unexpected, innocuously named user account in an internal LiteLLM deployment exposed to the public internet, and wrote: “We believe the attacker gained access to this deployment.” Help Net reported the company’s view that GitHub CLI OAuth tokens were then lifted from that deployment’s logs, along with LiteLLM’s observation that Claude Code can embed a user’s GitHub CLI token in a response body that may be logged.
That explanation did not hold. LiteLLM’s root cause analysis, published October 23, says the request logs show the first token came from a different service. The Hacker News led on that correction, reporting that the findings rule out the initial hypothesis, and set out the timeline step by step. The Record, on October 26, built its whole account around the cause: an exposed key that the company spotted, removed from the repository and failed to revoke.
The accounts also give different measures of scale. The Register, writing first, gave no count. The Record cites Wiz for about 49,000 downloads of the malicious package and for stolen cloud credentials being tested within hours, and adds that no affected organization has publicly confirmed a breach linked to the release. Help Net Security, citing Socket, and The Register both give about 23 million weekly downloads for LiteLLM, a figure for the project’s reach that says nothing about how many hosts ran 1.107.0.
The chain the root cause analysis describes
According to LiteLLM, a configuration file committed to a public repository on May 27 contained the master key to a deployment of its Agent Platform, an experimental tool for self-hosted agents that file pull requests. The commit was force-pushed over and the key was marked for revocation, but the master key was never revoked. The platform was configured with a GitHub CLI OAuth token belonging to one of the organization’s two owners. LiteLLM says the token was not associated with a service account and was not scoped down.
On October 10 the attacker used the master key to call the platform’s API, and one response returned the owner’s token. With owner access, the attacker pushed throwaway branches to two repositories whose workflows posted the repositories’ CI secrets to an outside endpoint, then deleted the runs within about three minutes. Those secrets held the GitHub CLI tokens of two more maintainers. On October 21 the attacker overrode branch protection with the owner’s token, repointed the release workflow at the lookalike repository, approved the production gate with a second maintainer’s token and deleted the run records with a third.
LiteLLM says a release normally needs approval from a special account locked to a physical device in its office, and that this rule had been relaxed that week so any two engineers could trigger and approve bugfix backports. Oliver Jensen, LiteLLM’s director of security, and Mateo Wang, an AI engineer, wrote in the analysis: “This incident has provided a strong illustration of the risks associated with failing to rotate a potentially exposed key.”
What the coverage adds up to
On October 25 Wiz published research on Gheist, a campaign it has tracked since September 15 that abuses stolen GitHub tokens at scale. Wiz says it has recovered more than 13,500 planted branches from more than 850 compromised accounts. The tool commits a workflow that writes the repository’s secrets into the run’s own log, encoded so that GitHub’s log masking does not recognise them, then downloads the log through GitHub’s API and deletes the run. Wiz says a recent GitHub control has blocked the exploitation in public repositories, and that it has seen successful exploitation in private repositories and GitHub Enterprise environments.
The LiteLLM attacker used the same pattern: a throwaway branch, a workflow that hands over the repository’s secrets, and a run deleted minutes later. Neither case needed a software vulnerability. The Hacker News, in its Gheist coverage, cites GitHub’s documentation that anyone with write access to a repository can read every secret configured in it. A token with write access is therefore a key to every CI secret it can reach, and an owner’s token, as LiteLLM found, also carries the power to switch off the branch protection meant to stop a bad push.
In our reading, that is what the four accounts add up to. The early coverage asked what the malware took from LiteLLM’s users. The later coverage shows that the decisive theft happened eleven days before the release, inside LiteLLM’s own GitHub organization, with a credential that had been exposed for more than four months. The controls LiteLLM described after its March incident, a private release repository, Trusted Publishers, immutable Docker tags and signed images, were in place and the pipeline still signed and published the attacker’s build, because it ran on identities the attacker already held.
What it means for the security leader
For teams that ran 1.107.0, the work is LiteLLM’s rotation list, carried out from a rebuilt environment. LiteLLM warns that running pip in an affected environment executes the malicious startup files again. For everyone else, the lessons sit in the chain.
Treat a leaked key as used
The May commit was caught and overwritten quickly. Overwriting the commit left the key valid. Revocation is the step that closes an exposure, and it belongs in the same ticket as the cleanup. GitHub’s push protection, which now blocks Anthropic API keys by default, stops some secrets before they land and has no effect on one that already has.
Give automation its own scoped identity
LiteLLM’s agent platform carried an owner’s personal CLI token. A dedicated service identity limited to the repositories and permissions the agent needs caps what a leak of that platform can expose. Inventory which tokens your agent and automation platforms hold, and whose accounts they belong to.
Hunt for deleted runs on short-lived branches
Both campaigns deleted their workflow runs within minutes. GitHub’s audit log still records the push, the run and the deletion, and LiteLLM says the log records a hash of the token behind each action. A detection for workflow runs on new branches that are deleted soon after they finish matches the October 10 activity, eleven days before the release. Wiz reports that Gheist branches use a ci-sync- prefix, and LiteLLM’s timeline shows ci-tmp- branches. Search your organizations for both, and review the account-takeover pattern behind the earlier GhostAction campaign that swept 345 repositories.
Decide how you consume the next release
This is LiteLLM’s second supply chain compromise of 2026. The March incident, which cascaded into a 2,500-firm breach according to Hudson Rock’s later analysis, started from a compromised scanner. LiteLLM says it will share its process changes next week. Teams running the gateway should read that document before deciding whether to keep pulling public releases on tags such as latest or to pin a reviewed version and move it forward on their own schedule.
Source: LiteLLM, Security incident October 21, 2026: attack chain and root cause, Oct. 23, 2026
