LiteLLM breach update: attackers deleted the logs

The official incident report is out, and it's worse than we thought. LiteLLM published its post-mortem on the October 21, 2026 supply chain compromise, and the details paint a picture of a sophisticated, coordinated attack that went far beyond the Git fork-injection technique initially reported by security researchers. The attackers didn't just spoof a repository — they hijacked three developer accounts, overrode GitHub branch protection, approved their own malicious release, and then deleted the workflow logs to cover their tracks.

This is an update to our earlier coverage. Here's what the official report changes, and why it matters.

What we got wrong — and what's new

When Wiz and JFrog first analyzed the malicious 1.107.0 release, the evidence pointed to a Git fork-object injection via a lookalike organization (Berri-AI with a hyphen). That was real, but it was only the delivery mechanism. The official report reveals the actual intrusion vector: stolen GitHub CLI OAuth tokens from three separate developer accounts.

The attackers used those three accounts in a carefully choreographed sequence:

This wasn't a script kiddie uploading a poisoned wheel. This was an operator who understood LiteLLM's CI/CD pipeline well enough to know which accounts could override branch protection, which could approve releases, and which could delete logs. The 12-second window between the two log-deletion actions suggests automation — the attacker had a script ready to wipe evidence the moment the release went live.

The full timeline, corrected

LiteLLM's report provides a minute-by-minute timeline that's more precise than earlier third-party analyses:

• 10:08:29 (UTC) — GitHub branch protection rejects an unauthorized modification to the private release workflow. The attacker doesn't have the right permissions yet.
• 10:08:34 (UTC) — Five seconds later, a privileged developer's credential is used to override the protection and apply the malicious workflow commit. The attacker had access to an account with admin-level repository permissions.
• 10:46:39 (UTC) — The modified workflow starts a staging run, pulling source from the attacker-controlled Berri-AI/litellm fork at commit 20535d8.
• 11:08:09 (UTC) — Staging completes successfully. No one notices.
• 11:08:53 (UTC) — Production release pipeline begins.
• 11:11:18 (UTC) — A second developer's credential satisfies the production approval gate. Two separate accounts, both compromised.
• 11:39:51–11:40:13 (UTC) — Seven malicious litellm==1.107.0 wheels hit PyPI over 22 seconds.
• 11:46:56 (UTC) — Docker images published, including latest, main-latest, and main-stable tags.
• 11:53:49–11:54:01 (UTC) — A third developer's credential deletes the workflow records. Evidence destroyed.
• 13:23 (UTC) — PyPI removes the malicious package.
• 14:20 (UTC) — Docker Hub tags finally removed or repointed — nearly an hour after PyPI.

The Docker exposure window is the most concerning correction. Earlier reports said both PyPI and Docker were cleaned up around 13:20 (UTC). The official report shows Docker Hub's latest tag continued serving the compromised image until 14:20 (UTC) — a full 2 hours and 33 minutes after the first malicious wheel was uploaded. Anyone who pulled docker pull litellm/litellm:latest between 11:46 and 14:20 (UTC) got the backdoor.

The extreme mitigation

LiteLLM's response has been drastic. The company has removed all but one user from its GitHub organization — essentially locking out its own engineering team — and revoked every token involved in the attack. Public registries have been updated to remove trusted links to the GitHub organization, preventing further malicious package publications through the compromised pipeline.

"We have not yet identified the mechanism by which the threat actor acquired the relevant tokens, so cannot yet assert that there is no further access to these GitHub accounts," the report states. That sentence is doing a lot of work. It means LiteLLM doesn't know how the tokens were stolen — phishing? malware? a compromised developer machine? — and therefore can't be sure the attackers don't still have a foothold.

The report also reveals that LiteLLM's private enterprise registry was not affected, and that enterprise customers are receiving an embargoed release fixing a separate vulnerability scheduled for public disclosure on October 27, 2026. That's a date worth watching — another LiteLLM security disclosure is coming in six days.

OpenAI's policy response — not a coincidence

On the same day as the LiteLLM breach, OpenAI announced an update to its Usage Policies, effective November 20, 2026, that directly targets the AI gateway layer that LiteLLM occupies. The new policy requires services that provide direct access to OpenAI models — such as model routers and AI gateways — to obtain OpenAI's review and approval before offering that access.

Read that again. OpenAI is now asserting the right to approve or deny any AI gateway that resells or routes access to its models. The timing — hours after the LiteLLM compromise was disclosed — is almost certainly not coincidental. OpenAI has watched two supply chain attacks hit the most popular open-source AI gateway in seven months, and it's responding by inserting itself as a gatekeeper.

This is a significant shift. Until now, anyone could spin up a LiteLLM proxy and offer OpenAI API access to customers. After November 20, that requires OpenAI's blessing. It's a move that favors established, well-funded gateway providers (Portkey, Helicone, Fireworks) over open-source projects maintained by tiny teams — and it effectively tells the market that OpenAI doesn't trust the open-source gateway ecosystem to secure its keys.

Why this changes the calculus

The initial third-party analysis framed this as a clever Git exploit. The official report reframes it as a targeted account-takeover operation against a specific AI infrastructure company. The three compromised accounts, the override-then-approve-then-delete-logs sequence, the 5-second branch-protection bypass, and the automated log wiping all point to an attacker who had done reconnaissance on LiteLLM's internal org structure and CI/CD configuration.

This isn't opportunistic malware. It's a surgical strike on a high-value target. And it raises the uncomfortable question: if LiteLLM — with 18,000 GitHub stars and millions of weekly downloads — can't protect its release pipeline with a team of 1-10 people, what does that say about the dozens of other open-source AI infrastructure projects with even smaller teams?

The economics are brutal. The reward for compromising LiteLLM is access to the API keys, cloud credentials, and GitHub tokens of tens of thousands of AI companies. The cost is a few phishing emails or a malware campaign against a handful of developers. That asymmetry isn't going away — it's getting worse as more companies consolidate their AI infrastructure around a small set of open-source chokepoints.

What to watch

• October 27, 2026: LiteLLM's embargoed vulnerability disclosure. If it's another critical issue, the project's security posture will be under serious question.
• Whether the attackers re-enter: LiteLLM removed all but one user from its GitHub org, but if the token-theft vector is still active (unknown malware on a developer machine, for example), the remaining account could be next.
• OpenAI's gateway approval process: How strict will the review be? Will open-source projects like LiteLLM qualify, or will this effectively force companies onto commercial gateways?
• The next target: LiteLLM was hit twice. vLLM, Ollama, and LangChain have similar trust profiles and even larger user bases. Attackers go where the keys are.

The official report closes with a promise to update every two hours. The next update was scheduled for 18:30 (UTC) on October 21. As of this writing, no further updates have been posted — which either means the situation is stable, or means the investigation has hit a wall. Given that the attackers deleted the workflow logs, "we don't know yet" may be the answer for a while.