LiteLLM says its public release pipeline was compromised on October 21, 2026, producing a malicious litellm==1.107.0 release on PyPI and compromised public Docker images.
LiteLLM’s incident post says the affected PyPI package was available from 11:39:51 to 13:23 UTC on October 21. Public container images on Docker Hub and GitHub Container Registry were also affected, including tags v1.107.0, latest, main-latest, and main-stable, with Docker Hub exposure lasting until 14:20 UTC.
The company said the official v1.107.0 source tag on GitHub did not contain the malicious files. The compromised artifacts were built from an attacker-controlled lookalike repository named Berri-AI/litellm, rather than the legitimate BerriAI/litellm repository.
PyPI’s record for the release shows litellm 1.107.0 was released and quarantined on October 21. It also shows the release files were uploaded using Trusted Publishing but had no provenance metadata attached. That separation matters: an authorized publishing route does not guarantee that the artifact came from the expected source tree if the release workflow itself was changed.
Why the malware ran even without importing LiteLLM
Microsoft Security Research said the affected wheels added cook.pth, cook.py, and sitecustomize.py into the Python environment’s library path. Because Python processes certain startup files when the interpreter starts, a routine Python or pip command in an affected environment could trigger the payload.
The credential collector targeted developer tools, AI applications, cloud environments, source-control and package ecosystems, browsers, private keys, process environments, and selected LiteLLM proxy data. Microsoft said a separate Unix-oriented path in sitecustomize.py supported remote retrieval and execution of additional Python code, although second-stage retrieval or execution had not been confirmed at the time of its analysis.
Who LiteLLM says should treat systems as compromised
According to LiteLLM, open-source users should treat systems as compromised if they installed litellm==1.107.0, including through an unpinned installation between 11:39 and 13:23 UTC on October 21, or if they used the affected Docker image tags v1.107.0, latest, main-latest, or main-stable during the exposure window. The company said enterprise customers using its private enterprise registry were not affected.
The cautious assumption in LiteLLM’s guidance is credential exposure. The company advised affected users not to start remediation by running pip install inside a suspect environment because Python startup could run the malicious files again. Its guidance included deleting cook.pth, cook.py, sitecustomize.py, killing the detached loader process, rebuilding images or virtual environments where possible, pinning to litellm==1.106.2, and rotating reachable secrets.
Those secrets include provider keys stored in the LiteLLM proxy database, master and virtual keys, the DATABASE_URL password, task or instance IAM roles, and environment secrets accessible to the host, according to LiteLLM’s remediation guidance. Microsoft separately recommended finding affected copies across package caches, mirrors, lock files, build outputs, and container images, then investigating from outside the affected environment with trusted tooling.
How the release process was subverted
LiteLLM’s October 23 analysis gives a more detailed chain than the initial incident post. It says a configuration file containing the master key for an internal alpha Agent Platform was committed to a public repository on May 27. The commit was force-pushed over, but the master key was not revoked.
According to the company, the attacker used that key on October 10 to call the Agent Platform API and retrieve a GitHub CLI OAuth token associated with a GitHub organization owner. The attacker then used GitHub workflows to send repository secrets to an external endpoint, including tokens associated with two maintainers.
On October 21, LiteLLM says the attacker changed the private release workflow so it built from the lookalike repository. One token started the release, another approved the production gate, and a third deleted workflow records. PyPI quarantined the package by 13:23 UTC, and Docker Hub tags were removed or repointed by 14:20 UTC.
The second LiteLLM supply-chain incident in 2026
Security researchers also flagged the October incident as the second LiteLLM supply-chain compromise reported in 2026. In March, LiteLLM disclosed that PyPI versions 1.82.7 and 1.82.8 were compromised. Datadog Security Labs said no connection between the March and October compromises had been established at the time of its October write-up.
The repeated pattern is not limited to one project. It shows how AI gateway tooling can become a high-value target because it often sits close to model-provider keys, database credentials, cloud identities, CI secrets, and developer workstations. A compromised dependency in that position can become a credential collection point before any application-specific vulnerability is involved.
What security teams can take from the incident
The useful check is whether artifact provenance, lockfile hashes, container digests, and release workflow permissions all tell the same story.
Mutable tags such as latest also created exposure for teams that may not have intentionally selected version 1.107.0. Microsoft recommended container digests instead of floating tags, hash-pinned lock files, package and image provenance checks, internal mirror review, and restricted outbound traffic for developer systems, build agents, containers, and AI gateway hosts.
Get new small business insights by email
Practical ideas and useful articles to help you make better business decisions.
Tech Help Canada Staff researches, writes, and reviews practical content for business owners and professionals. Our coverage spans business, marketing, SEO, technology, and the tools and systems people use to grow and operate online. We focus on clear, useful information backed by research, hands-on experience, and editorial review. Learn more about our team and editorial standards. Need help with something? Contact Us
