“On October 21, 2026, LiteLLM 1.107.0 was published to PyPI and Docker with a credential stealer and an hourly remote code loader. There is no CVE. Here is how the release pipeline was hijacked, what the malware takes, the exact cleanup steps, and what it teaches anyone whose Next.js or Laravel app talks to LLMs through a gateway.”

Short answer: if litellm==1.107.0 or a LiteLLM Docker image pulled on October 21, 2026 ever ran on one of your machines, treat that machine as compromised. Kill the hidden loader first, rebuild from scratch on 1.106.2, rotate every secret the machine could reach, and block litellm.dev. There is no CVE, so your dependency scanner may not warn you.

Watch the video:

I call LLM APIs from my own Next.js and Laravel projects, often through a gateway like LiteLLM, so this one hit close to home. Here is what happened and what I changed.

What happened

LiteLLM is a popular open-source gateway: one OpenAI-style API in front of OpenAI, Anthropic, Gemini, Bedrock and others, plus virtual keys, budgets and logging. On October 21, 2026, version 1.107.0 was published with malware inside:

• PyPI: all seven litellm==1.107.0 wheels, live from 11:39 to about 13:23 UTC.
• Docker: v1.107.0 and the floating tags latest, main-latest and main-stable on Docker Hub and GHCR (litellm, litellm-database, litellm-non_root), from 11:46 UTC until about 14:20 UTC on Docker Hub.
• The v1.107.0 source tag on GitHub is clean. The poison was only in the built packages and images.

A few hours sounds short, but anything that ran pip install litellm without a pin, or pulled :latest, in that window got the bad build.

How the release pipeline was hijacked

This is the part every developer should read, because it starts with tokens in logs. According to LiteLLM’s own post-mortem (still under investigation):

1. The attacker got into an internally exposed LiteLLM deployment through an unexpected user account.
2. That deployment logged response bodies, and the logs contained GitHub CLI OAuth tokens for three developers.
3. One token belonged to a GitHub organization owner. The attacker used it to override branch protection and point the private release workflow at a lookalike repository, Berri-AI/litellm (note the hyphen).
4. The official pipeline then built, signed and published the poisoned artifacts. A second developer’s token passed the approval gate.
5. A third token was used to delete the workflow run records.

No zero-day in your code, no typo-squatted package name. A trusted name, a trusted pipeline, a real signature, all because secrets ended up somewhere they should never be.

What the malware does

Three files land in site-packages:

What it goes after:

• AWS keys from files and instance/ECS metadata, tested with AWS STS before sending. Also Azure, Google Cloud and Kubernetes credentials.
• SSH, GPG and TLS private keys, .env files, .git-credentials, .npmrc, .pypirc.
• Environment variables of every readable process, so secrets passed to other apps on the same box leak too.
• If DATABASE_URL is set: the LiteLLM proxy database, which means every provider API key you saved in the gateway.
• Browser passwords and cookies, and credentials of AI coding tools.

A note on the headline “one pip install stole their AWS keys”: the malware clearly targets and validates AWS keys, but as of today no report names a victim whose keys were used. LiteLLM’s advice is still to assume exfiltration succeeded on any affected host with internet access.

Am I affected? Quick checks

# 1. Pinned or resolved to the bad version?
grep -rn "litellm" requirements*.txt poetry.lock uv.lock Pipfile.lock 2>/dev/null

# 2. Images you pulled or run
docker images --digests | grep -i litellm

# 3. Payload files in any environment (use find, not Python)
find / -path "*site-packages*" \( -name "cook.pth" -o -name "cook.py" \) 2>/dev/null
ls -la /tmp/remote_code_loader.lock /tmp/.pc_once_72129118c59f5636c0bb 2>/dev/null

Also search DNS and egress logs for litellm.dev, and AWS CloudTrail for GetCallerIdentity calls from your instance roles around the install time.

The fix, in order

1. Kill the loader first. Find the process holding /tmp/remote_code_loader.lock and stop it. Don’t run pip in the infected environment before this.
2. Remove the payload (cook.pth, cook.py, sitecustomize.py and their __pycache__ files), then rebuild the virtualenv or image from scratch on litellm==1.106.2. Pin the image by digest.
3. Purge caches: internal PyPI mirrors, pull-through registries, CI caches.
4. Rotate everything the host could reach: cloud keys and role sessions, every provider key in the LiteLLM database, the master key, virtual keys, the database password, SSH keys, Git and registry tokens, CI secrets.
5. Block litellm.dev at DNS and egress.

The lesson for Next.js and Laravel apps

Most of us don’t run Python in our web apps. But if your Next.js route handler or Laravel service sends prompts to a gateway, that gateway is the single box that holds all your AI keys. Compromise it once and every provider key leaks.

1. Never log tokens or request bodies

The whole attack started with tokens in logs. Check the usual suspects:

// Laravel: don't do this
Log::info('LLM call', ['headers' => $request->headers->all(), 'body' => $response->body()]);

// Do this: log what you need, never secrets
Log::info('LLM call', ['model' => $model, 'status' => $response->status(), 'ms' => $ms]);

In Laravel, also hide the authorization header in Telescope (Telescope::hideRequestHeaders) and scrub it in your error tracker. In Next.js, never console.log(req.headers) in a route handler: on most hosts those logs are kept and searchable.

2. Pin versions and image digests

litellm>=1.100 or image: litellm:latest is exactly how this build reached people. Pin exact versions in lock files and pin containers by digest:

image: ghcr.io/berriai/litellm@sha256:<digest-of-1.106.2>

3. Give each app its own small key

Use gateway virtual keys per app with budgets and rate limits, and keep the real provider keys out of your app servers. If one key leaks, you rotate one key.

4. Don’t expose the gateway

The attacker’s way in was an exposed internal deployment. Put the admin UI and API behind a VPN or private network, and allow only your app servers to reach it.

Checklist

• Searched lock files and images for litellm 1.107.0 and floating tags pulled on Oct 21
• Killed the loader, rebuilt from scratch on 1.106.2, purged caches
• Rotated cloud, LLM provider, gateway, database, SSH and Git secrets
• Blocked litellm.dev
• Removed tokens and request bodies from logs (Laravel, Next.js, error tracker)
• Pinned versions and image digests

Watch the video:

Sources

• LiteLLM incident post (Oct 21, 2026): https://docs.litellm.ai/blog/security-incident-oct-21-2026
• StepSecurity analysis: https://www.stepsecurity.io/blog/litellm-1-107-0-compromised-pypi-backdoored-wheels-credential-stealer
• Socket analysis: https://socket.dev/blog/litellm-compromise
• Datadog Security Labs: https://securitylabs.datadoghq.com/articles/litellm-compromised-pypi-docker/

FAQ

Is there a CVE for the LiteLLM 1.107.0 compromise?
No. It is a supply-chain compromise, not a code bug, so no CVE or GHSA was assigned. Scanners that rely on CVE databases may not flag it.

Which LiteLLM version is safe?
LiteLLM recommends pinning litellm==1.106.2 or another version published before October 21, 2026. 1.107.0 was removed from PyPI.

I only use LiteLLM’s Docker image. Am I affected?
Yes, if you pulled v1.107.0, latest, main-latest or main-stable between about 11:46 and 14:20 UTC on October 21. Check your running containers’ image digests.

My app is Laravel or Next.js, not Python. Should I care?
If your app talks to a LiteLLM gateway, the gateway host held your provider keys. Rotate them if that gateway ran the bad version, and apply the logging and pinning lessons above.