LiteLLM's release pipeline pushed a tampered litellm==1.107.0 package to PyPI starting around 11:39Z on October 21, and it stayed live until roughly 13:23Z. Matching Docker and GHCR images tagged v1.107.0, latest, main-latest, and main-stable were compromised from about 11:46Z to 14:20Z. Three payload files, cook.pth, cook.py, and sitecustomize.py, executed on every Python interpreter start, meaning any process that imported the package during that window ran attacker code automatically, not just at install time.
LiteLLM published an incident post on October 21 and updated it at 20:30Z with an identified attack chain, confirming the malicious releases had been pulled from both PyPI and the container registries. The vendor has confirmed the exact package versions and image tags affected, the approximate time windows for each distribution channel, and that the GitHub tag for v1.107.0 is clean, meaning the source repository was not the entry point. The enterprise private release was not affected. The vendor's update does not spell out how the pipeline itself was breached, so the entry point into the release process remains undisclosed.
Pinning to 1.106.2 is the vendor's stated known-good version, and that detail matters more than it looks. A sitecustomize.py payload does not require anyone to call a malicious function, it runs by default on interpreter startup, so any container built or redeployed inside the roughly two-and-a-half-hour PyPI window, or the shorter Docker window, is suspect regardless of whether the application code ever touched the compromised features. Anyone running litellm in production should treat image digests pulled between 11:39Z and 14:20Z on October 21 as untrusted rather than checking version strings alone, since latest and main-latest tags moved during that period.
For on-call engineers, the practical first step is grepping build and deploy logs for pulls of litellm 1.107.0 or the named Docker tags inside the confirmed windows, then checking whether sitecustomize.py or cook.py exist in any running container's Python path. Image digest history matters more than tag names here, because latest and main-stable were among the compromised tags, so a redeploy that happened to land in that window could have pulled a poisoned image without any version bump showing up in a changelog. Credential rotation is a reasonable precaution for any environment that ran the affected package, given the incident involves a credential stealer, though the vendor has not published a list of which credentials or secrets the payload targeted.
The vendor's security record on this kind of event was clean before October 21, which is part of why a two-hour window matters: there was no prior pattern suggesting extra scrutiny of release artifacts was warranted. The attack chain identified by evening on the same day gives responders a starting point, but the unresolved question is how the pipeline was accessed in the first place, and that gap is exactly the detail that determines whether pinning to 1.106.2 is a temporary fix or a long-term posture.