LiteLLM's release pipeline pushed a malicious version of litellm, tagged 1.107.0, to PyPI starting around 11:39Z on October 21 and left it live until 13:23Z. Docker images carrying the same compromise, including v1.107.0, latest, main-latest, and main-stable, stayed up longer, from roughly 11:46Z to 14:20Z. Anyone who pulled a fresh install or rebuilt a container in that window got three payload files: cook.pth, cook.py, and sitecustomize.py. Because Python's site module loads .pth files automatically, cook.py ran on every single Python process start, not just on LiteLLM invocation. That is the detail that matters: a poisoned package doesn't wait to be imported, it executes the moment the interpreter boots.
The vendor published an incident post the same day and updated it at 20:30Z with an identified attack chain. That update is confirmed: malicious releases have been pulled from both PyPI and the registries serving the Docker tags. The vendor also confirms the GitHub tag v1.107.0 itself is clean, meaning the compromise happened somewhere in the build or publish step between tagging and distribution, not in the source tree. The enterprise private release was not impacted, according to the same post. What the incident post does not disclose is how the pipeline was breached in the first place, so the entry point for whoever inserted cook.pth remains an open question outside the scope of what's been confirmed.
For teams running LiteLLM in production, the fix path is narrow and specific. The vendor's guidance is to pin to 1.106.2, the last known-good version before the compromise. That is not a recommendation to wait and see. Any automated pipeline that pulls litellm by floating tag, whether that's pip install litellm with no version pin or a Docker pull against latest or main-latest, was exposed to the compromised artifact during the live windows. Rebuilding from a cached layer built before 11:46Z on October 21 is safe. Rebuilding anything after that timestamp, even today, requires checking whether the registry had already served the bad image before the vendor's pull.
On-call engineers should treat this as a credential-exposure event until proven otherwise, not a routine dependency bump. Check deployment logs for any pip install or docker pull of litellm timestamped between 11:39Z and 14:20Z on October 21. If a build during that window reached production, rotate any credentials that process had access to, including API keys, database connection strings, and cloud IAM tokens, since cook.py ran at interpreter startup with whatever privileges the process held. Container image digests, not tags, are the only reliable way to confirm which build actually shipped, because latest and main-latest point to different content depending on when they were pulled.
This incident has no prior security record attached to LiteLLM, which is part of why a compromised build sat live for close to two hours before detection. Supply-chain compromises of this shape, where the tag is clean but the published artifact is not, break the usual trust assumption that version-pinned installs are safe by default. They are not, if the pin happens to land on the compromised version. The vendor's status is OPENED_AND_SUPPORTS, with high confidence in the discovery, but confirmation of root cause in the pipeline itself is still pending as of the 20:30Z update.
Pin to 1.106.2, verify image digests against anything pulled after 11:46Z on October 21, and rotate credentials for any process that ran the compromised build.