LiteLLM 1.107.0 Supply Chain Compromise: What Happened and What IT Teams Should Do Now

The incident matters beyond one package. LiteLLM is widely used to route calls to AI model providers, so the machines that run it often hold provider keys, cloud credentials and developer tokens.

Below is a verified summary of what the vendor and independent researchers reported, why it matters for B2B software buyers, and a checklist your IT and security teams can run today.

What happened

On October 21, 2026, a malicious version of the open-source LLM gateway LiteLLM, version 1.107.0, was published to PyPI and to its Docker images. According to LiteLLM, the PyPI release was live from about 11:39 to 13:23 UTC, and Docker tags were affected between 11:46 and 14:20 UTC.

LiteLLM's incident report says a compromised release pipeline pushed the package, which contained malware that steals credentials and loads remote code execution tools. Datadog Security Labs, in its technical analysis, says a .pth file runs the payload whenever any Python process starts, even if LiteLLM is never imported. The Hacker News reported that PyPI quarantined the package and the Docker images were removed.

The stolen data, per Datadog, includes cloud credentials, developer tokens, AI provider keys, browser data and LiteLLM proxy credentials. LiteLLM says all earlier versions are safe, and that its enterprise customers on the private release were not affected.

How the attackers got in

LiteLLM says attackers used stolen GitHub CLI OAuth tokens from three engineers to run its private release workflow against a lookalike repository. How those tokens were first obtained is not confirmed, and LiteLLM has said earlier assumptions in its report were incomplete.

Datadog notes the malicious repository name differs from the real one by a single hyphen, and that the release carried build provenance recording the fork as its source. This is the second LiteLLM compromise in 2026. An earlier incident in March affected versions 1.82.7 and 1.82.8, and no link between the two has been established.

Why it matters for B2B SaaS buyers

LLM gateways sit between applications and model providers, so they hold the API keys, usage data and routing rules for AI features. A compromise there can expose provider credentials and, through the host environment, cloud and developer secrets.

• Wide blast radius: any build, notebook or container that installed the package may have run the payload.
• Persistence: LiteLLM and Datadog both say uninstalling is not enough, because the dropped files must be removed manually.
• Short window, long exposure: the malicious release was live for roughly two hours, but automated builds and unpinned installs can pull a bad version quickly.
• Provenance gaps: teams that trust a registry release without checking where it was built are exposed to this pattern.

What to do now

Check whether any system installed litellm 1.107.0 on October 21, then treat affected hosts as compromised. Remove the dropped files, rebuild from clean images, pin to a safe version, and rotate every credential those hosts could reach from a clean machine.

Response checklist

• Search lockfiles, CI logs, container image histories and virtual environments for litellm==1.107.0 and for cook.pth, cook.py and sitecustomize.py.
• Rebuild environments and images from scratch, and pin LiteLLM to 1.106.2 or another version published before the incident.
• Rotate cloud keys, SSH keys, Git and package registry tokens, LLM provider keys, database passwords and anything in process environments.
• Review cloud audit logs for use of those credentials from outside your infrastructure after the install time.
• Block outbound traffic to the exfiltration domain named in the vendor reports, and hunt for the hourly beacon behavior described by Datadog.

Absence of the marker files does not prove a host is clean, according to LiteLLM, so rotate credentials whenever installation is confirmed.

Lessons for your software supply chain

This incident repeats a familiar lesson: package registries are part of your attack surface. Pin dependencies by version and digest, require provenance checks, and limit what build systems and developer tokens can publish or reach.

NIST SP 800-218 describes secure development practices in the Secure Software Development Framework, and NIST SP 800-161 covers supply chain risk in its cybersecurity supply chain risk management guidance. Practical steps include delaying adoption of brand-new releases, mirroring approved packages internally, using short-lived tokens for release workflows, and treating developer CLI tokens as high-value secrets.

If your team runs an LLM gateway, review LiteLLM guidance and compare access controls in our Privileged Access Management software category. Teams tracking exposure can look at Vulnerability Management software and AI Code Generators software, and our related coverage of the AOMEI Backupper update server attack shows the same supply chain pattern.

Sources

This article draws on LiteLLM's security incident report (October 21, 2026, with a later note on October 23), Datadog Security Labs (October 21, 2026) and The Hacker News (October 21, 2026). We will update it if LiteLLM publishes confirmed root cause findings.

Frequently Asked Questions

Which LiteLLM versions were affected?
Only litellm 1.107.0 on PyPI and the v1.107.0, latest, main-latest and main-stable Docker tags during the incident window. LiteLLM says all earlier versions are safe and recommends pinning to 1.106.2 or a version published before October 21, 2026.

Is uninstalling LiteLLM enough to remove the malware?
No. LiteLLM and Datadog both say the dropped files run whenever Python starts, so you must delete them manually, rebuild from clean images and rotate every credential the host could reach.

Should we stop using LiteLLM?
That is a risk decision for your team. Pin to a known safe version, add provenance and hash checks, monitor the vendor root cause findings, and prepare an alternative gateway plan if your risk tolerance for the vendor release process is low.