An AI gateway shipped malware for two hours. The trust failure began before the package

The malware did not arrive disguised as a mysterious download from an unknown website. On 21 October, a malicious LiteLLM release briefly reached the normal Python package registry and official container channels. That distinction is why the incident matters to any organisation building with AI services. LiteLLM is middleware for routing requests to different model providers; compromising the machine running that middleware can expose exactly the API keys and cloud privileges that keep an AI application operating.[1]

LiteLLM's incident report says seven malicious wheels for version 1.107.0 were uploaded to PyPI between 11:39:51 and 11:40:13 UTC and removed by 13:23. Affected Docker Hub tags remained pointed at a compromised image until about 14:20. The firm says earlier versions were safe, and its separate private enterprise release was not affected. These are statements about known distribution artifacts at the time of the report, not a guarantee that every connected credential escaped theft.[1]

How a protected release was made to trust the wrong source

The attacker apparently held GitHub command-line credentials associated with three developers. According to the project's timeline, a branch-protection check blocked an unauthorised workflow change at 10:08:29. Five seconds later a privileged credential overrode it. A second credential approved production publishing; a third was used to remove workflow records. The pipeline built material from a lookalike repository, Berri-AI/litellm, instead of the legitimate BerriAI/litellm. The official tagged source tree did not itself carry the malicious additions.[1]

This is a failure of source identity and release authority rather than merely a failure to sign a package. A published artifact can be signed by legitimate automation and still be malicious if the automation was instructed to build the wrong repository. Datadog's analysis reinforces that point: apparently credible provenance can faithfully describe an untrustworthy source. That is why teams need repository allowlists, protected publication identities and independent approvals designed to resist a compromised engineer account.[2]

A short exposure window can have a long tail

The compromised package included code that ran when Python started, harvested secrets and supported remote commands. The reported targets extended beyond LLM service keys into cloud credentials, developer tokens, local environment files, browser information and the LiteLLM proxy's stored upstream provider credentials. The exposure is therefore not measured by the number of minutes a package remained downloadable, but by which machines executed it and what those machines could access afterwards.[2]

LiteLLM advises organisations that installed or ran the affected release to assume compromise. It recommends rebuilding affected environments from clean sources, removing the malicious startup files and rotating exposed credentials. It cautions that launching Python—including the pip command—in a compromised environment may execute the malicious startup hook again. The safest operational procedure is to investigate from a trusted host or clean environment, not to casually run package-maintenance commands inside the suspect one.[1]

The project's report distinguishes confirmed facts from unknowns. Three developer identities were involved and the compromised release was withdrawn, but the initial route by which attackers obtained the tokens had not been established. Datadog says an earlier LiteLLM compromise in 2026 was associated with different activity and that no link between the two incidents had been demonstrated. Conflating them into a single campaign would overstate the evidence available on 22 October.[1][2]

The immediate lesson is concrete: treat dependency publication as part of production security. Record installed artifact versions and digests, restrict CI jobs to approved source repositories, require independent approval for changes to release workflows and keep model-provider credentials narrowly scoped. AI applications often make one gateway central to many services. That convenience amplifies the consequences when a gateway's distribution system is compromised.[1][2]

Report an error or suggest a correction