LiteLLM 1.107.0 compromise for AI app builders: are you affected?

Version 1.107.0 of the LiteLLM Python package was malicious for a few hours on October 21, 2026. Here is who it can reach in an AI-built app, how to check, and what to rotate.

Timothy Lindblom

Founder, Newly

October 24, 2026|8 min read

Published October 24, 2026Last updated October 24, 2026

You are affected only if a server, build machine or tool behind your app installed litellm 1.107.0 from PyPI, or started the matching Docker image, during the windows on October 21, 2026. An Expo phone app does not contain the package. If something you run did, LiteLLM tells you to rebuild that host and rotate every secret it could read.

What happened, and when?

LiteLLM is an open-source Python library and proxy that many teams use as a single gateway to AI providers. On October 21, 2026, its incident report says attackers used stolen GitHub credentials to push a release workflow pointed at a lookalike repository. The official source tag stayed clean. The artifacts built from the lookalike carried code that steals credentials. The report was last updated October 21 at 20:30 UTC, and we checked it again on October 24, 2026 with no later update.

Artifact	Affected	Window (UTC, Oct 21)
PyPI	`litellm==1.107.0`, all seven wheels	11:39 to 13:23
Docker Hub	Tags v1.107.0, latest, main-latest, main-stable	11:46 to 14:20
GHCR	berriai/litellm, litellm-database, litellm-non_root	11:46 to 13:51
Not affected, per LiteLLM	Earlier versions, the official source tag and the private Enterprise registry	Not applicable

These figures are LiteLLM's own. Datadog's analysis describes the same files and calls it the second LiteLLM supply chain compromise of 2026. The OpenSSF malicious-package record for litellm lists 1.107.0, and PyPI shows the release quarantined. LiteLLM says the attackers used GitHub CLI OAuth tokens taken from internal deployment logs.

Does a LiteLLM compromise reach an app built with AI?

Newly builds a real iPhone and Android app with React Native and Expo. That app is JavaScript, and a Python package does not ship in its bundle. So the risk is not on the phone. It sits where Python runs in your project, and an AI feature is the usual reason it does.

The phone app is on the left for orientation. The affected package, if you have it, lives in the middle box.

If your project has	What it means	Do this
A LiteLLM proxy you host as your AI gateway	Highest relevance. It holds provider keys by design.	Check the image digest and start time of every container.
A Python backend or script that lists litellm	Relevant if it was installed or rebuilt on October 21.	Read the lockfile and the deploy or CI log for that date.
A tool or agent framework that depends on litellm	Indirect. You may not have chosen the package.	Run `pip show litellm` in each Python environment you use.
Only Expo, Supabase or Firebase and a hosted AI API	No LiteLLM in your own code. Unknown for third-party services.	Ask any vendor holding your keys whether they use it.

If you only call an AI provider from a server function, you can still check your own side: Expo's documentation warns that variables starting with EXPO_PUBLIC_ are visible in plain text in the compiled app. A provider key does not belong there, and our 15-minute check covers it.

How do I check if I ran it?

Work from records first, because opening a Python shell on a suspect host can run the problem again. LiteLLM states that the malicious files run when Python starts, including when pip starts, and that you should not run pip in an affected environment before removing them. Python's own documentation confirms that .pth files can run code at startup.

Open your lockfile history, CI logs and deploy logs for October 21, 2026. Look for litellm 1.107.0 or an unpinned install that ran between 11:39 and 13:23 UTC.
For containers, find the image digest each one started from. LiteLLM lists the affected index digest in its report. A tag such as latest tells you nothing, because it moves.
Only after that, search the host for the files LiteLLM names: litellm-1.107.0.dist-info, cook.pth, sitecustomize.py and the lock file /tmp/remote_code_loader.lock.

Reading the result

Finding the files confirms exposure. Not finding them does not confirm the host was never exposed, because the cleanup steps delete those files, and someone may already have run them. Records of what was installed, with times, carry more weight than a file search.

What do I do if it ran?

Follow LiteLLM's remediation steps from its report rather than a summary of them. The outline, as of October 24, 2026:

Treat the host as compromised. Remove the startup files and stop the background Python process the report describes, or better, rebuild the environment or container from scratch.
Reinstall an earlier release such as litellm==1.106.2, the latest release on PyPI at our check.
If the host had internet access, assume the secrets it could read were taken. Do the rotation from a different, trusted machine.

Rotate	Where	Then check
AI provider keys	Each provider dashboard and your proxy database	Usage and billing for odd spikes
LiteLLM master and virtual keys	The proxy admin and its database	Who and what holds a virtual key
Database password in `DATABASE_URL`	Your database host	Connections from unknown sources
Cloud instance or task role	Your cloud console	Audit log for use of the role from outside your setup
Every other environment secret on the host	The issuing service for each	Each service's own access log

Create the new secret, switch the app or server to it, then revoke the old one. Our guide is rotating secrets after a breach. LiteLLM's own docs add one catch: its salt key cannot be rotated once models are added, because it encrypts the stored provider credentials, so read the deployment page before touching it.

Where do you stand?

Everything starts as unknown. Move an item to confirmed only when you hold the evidence under it. Detected means you found the problem on one of your hosts.

Your LiteLLM check

Detected: You found the problem.
Unknown: Not checked yet, or the check could not tell.
Confirmed by owner evidence: You checked and kept the proof.

1. I know every place that installs litellm: backend, gateway container, CI, scripts and laptops.
Evidence: a list of hosts and repositories with the output of pip show litellm or your lockfile entry.
2. None of those places ran litellm 1.107.0 or the affected image digest on October 21, 2026.
Evidence: lockfile history, CI logs with install times and the image digest each container started from.
3. No host shows the startup files LiteLLM lists in its report, and the lock file it names is absent.
Evidence: a dated note of each search, run only on hosts where Python has not been started since the install.
4. If any host ran the bad version, every secret it could read has been replaced at its provider and the old one revoked.
Evidence: a provider-side list showing the old key revoked and the new key created after October 21.
5. Provider and cloud logs show no calls from addresses or roles you do not recognise since October 21.
Evidence: an export or screenshot of usage and audit logs with the date range visible.
6. Installs use a lockfile with hashes, and containers are pinned by digest rather than a moving tag.
Evidence: the lockfile and the image reference in your deployment config.

0 detected6 unknown0 confirmed by owner evidence

Your answers stay in this browser tab. Nothing is saved or sent.

How do I stop this reaching me next time?

This was the second LiteLLM compromise of 2026, after the one PyPI described in an April incident report. That report says many of the people who received the malicious code had pulled the latest version without pinned dependencies. Three habits narrow that exposure:

Install from a lockfile with hashes. pip's hash-checking mode refuses a file whose hash is not in your requirements.
Pin containers by digest, not by tag. Docker documents pulling by digest as the way to get a specific, unchanging image, and LiteLLM's deployment docs say to pin a version rather than latest.
If you publish packages yourself, use trusted publishers, which swap long-lived tokens for short-lived ones.

The same habit applies to npm in an Expo project. See the npm worm check and the October 2026 tracker for other incidents that month. The hub for all of this is Newly security.

Frequently asked questions

Is every version of LiteLLM compromised?

No. LiteLLM's incident report names version 1.107.0 and the Docker tags that pointed to it inside exact time windows on October 21, 2026. It says earlier versions and its private Enterprise registry were not affected, and it names 1.106.2 as an earlier release to pin. The official source tag was clean; the bad artifacts came from a lookalike repository.

My app runs on a phone. Do I need to do anything?

Only if a server, build machine or tool behind the app runs Python. An Expo app's JavaScript bundle does not contain a Python package. Check the backend, any AI gateway you host, your CI and any developer laptop that installs Python packages for the project.

I only use OpenAI or Anthropic keys in my backend. Does that change anything?

It changes what you rotate, not whether you rotate. If a host ran the bad version, LiteLLM says to assume credentials that process could read were taken, which includes provider keys, database passwords and cloud roles. Rotate each at the provider, then check the provider's usage log for calls you did not make.

Can I just upgrade LiteLLM and move on?

Not if the bad version ran. LiteLLM says the startup files stay behind and that running pip can trigger them again, so the host should be isolated and rebuilt from scratch, and credentials rotated from a different machine. Changing the version number does not undo what a process already read.

Does a free scan of my website show whether I was hit?

No. The free scan on red.run.cloud reads the technologies your public site serves and matches versions to known vulnerabilities. A package on a build machine or inside a private container never shows up in that view, so it stays unknown until you hold the evidence described on this page.

Sources

All sources were opened on October 24, 2026.

LiteLLM v1.107.0 security incident report, October 21, 2026, LiteLLM
MAL-2026-2144, malicious code in litellm (PyPI), OSV, OpenSSF Malicious Packages
LiteLLM supply chain compromise: what you need to know, Datadog Security Labs
litellm release history, 1.107.0 quarantined, PyPI
Incident report: LiteLLM/Telnyx supply-chain attacks, April 2, 2026, PyPI blog
site: .pth files and startup behaviour, Python documentation
Secure installs and hash-checking mode, pip documentation
Trusted publishers, PyPI documentation
docker image pull: pull an image by digest, Docker documentation
Deploying the proxy: pin a version, not latest, LiteLLM documentation
Environment variables in Expo, Expo documentation