A standard pip install was enough. In the early hours of October 21, 2026, LiteLLM’s release pipeline published version 1.107.0 with a credential stealer and a remote-code loader inside every official wheel. The company’s incident report says a malicious litellm==1.107.0 package “was published to PyPI and was live for approximately 2 hours (11:39 UTC to 13:23 UTC).” Docker images v1.107.0, latest, main-latest and main-stable were compromised from 11:46 to 14:20 UTC. “All previous versions are safe, and the impacted releases have been pulled. Enterprise Customers running the private enterprise release of LiteLLM were not impacted.”
Quick Take
- What shipped: All seven PyPI wheels for 1.107.0, plus official Docker Hub and GHCR tags, contained
cook.pth,cook.pyandsitecustomize.py. The payload runs at Python startup, even if the app never imports LiteLLM. - What was clean: The official GitHub source tag for 1.107.0 did not contain the malicious files. The wheels were built from an attacker-controlled lookalike repository,
Berri-AI/litellmrather thanBerriAI/litellm. - If you are affected: Do not start Python or pip in that environment. Delete the payload files from site-packages first, kill the loader daemon that holds
/tmp/remote_code_loader.lock, rebuild and pinlitellm==1.106.2, then rotate every secret the host could reach. - Context: JFrog notes this is LiteLLM’s second documented hijacking in 2026, after a March incident. Socket later reported that secret-exfiltration workflows had already run in the real repository on October 10 and 12, eleven days before the release.
What happened
JFrog Security Research analysis is the clearest technical account of the package itself: the wheels are a functional copy of the legitimate project plus three startup-hook files. Because they live in the wheel’s purelib and are hooked through .pth and sitecustomize, any Python interpreter start in that environment runs the malware. The published source distribution did not include those three files, so a review of the Git tag or the sdist would miss them.
LiteLLM’s own timeline says an attacker who had obtained GitHub CLI OAuth tokens — the company believes from logs of an internal LiteLLM deployment, in which Claude Code had embedded tokens in a response body — overrode branch protections, pointed the release workflow at the lookalike repo, and pushed the poisoned artifacts through the official publishing path. PyPI removed 1.107.0 by 13:23 UTC; Docker Hub tags were cleaned by 14:20.
The company later cautioned that some early statements in the post were “inaccurate or incomplete” and pointed to a canonical record. The containment facts, affected artifacts, and user remediation steps above are from the published incident report as it stood, including those later caveats.
Socket subsequently reported a longer compromise window: malicious cache.yml workflows on short-lived ci-tmp-* branches in BerriAI/litellm ran successfully on October 10 and October 12, then the branches were deleted. That finding does not change the user remediation for 1.107.0; it does change how long the GitHub organization should be assumed to have been accessible to the attacker.
What you should do
Follow LiteLLM’s order of operations, which it credits to an external helper:
- Do not run
pip installor start Python in a suspect venv or image first — that re-runs the payload. - Delete
cook.pth,cook.py,sitecustomize.pyand matching bytecode from every affected site-packages, then kill the detached Python process holding/tmp/remote_code_loader.lock. - Rebuild from scratch and pin
litellm==1.106.2(or another verified later release, once you trust the new signing key LiteLLM rotated on October 23). - If the host had outbound internet, assume exfiltration succeeded. Rotate instance IAM roles, every provider key in the LiteLLM proxy database, master and virtual keys, the
DATABASE_URLpassword, and any other secret in the environment. Check CloudTrail forGetCallerIdentityfrom the instance role around install time.
What it means
LiteLLM sits in front of a lot of production model traffic, which is why a two-hour window still matters: CI jobs and unpinned latest tags can install a release in minutes. The second 2026 compromise, the lookalike-repo trick, and Socket’s evidence of earlier secret-stealing workflows make this more than a one-off typo in a pipeline. If you consumed 1.107.0, the incident is not over when the package is yanked; it is over when the secrets that machine could see have been rotated and the environment has been rebuilt.
About the analysis
Researched and written with AI assistance under the editorial responsibility of the i10X News team. The title image is an AI-generated illustration. Read our AI Use Policy. Spotted an error? Request a correction.
This i10x report is based on LiteLLM’s October 21 incident report (including later updates on that page), JFrog’s technical analysis, and Socket’s follow-up on the October 10–12 workflows. i10x did not analyze the malicious wheels.
