Skip to main content
TACAVAR
•Updated •AI Agent Governance

LiteLLM 1.107.0 Compromise: What to Rotate

LiteLLM 1.107.0 was a malicious PyPI and Docker release on Oct 21, 2026. Check without running Python, remove the backdoor, rotate in order.

If you installed litellm==1.107.0 from PyPI, or started the v1.107.0, latest, main-latest or main-stable Docker images on October 21, 2026 within the windows below, treat the host as compromised and rotate every credential it could reach. Earlier versions are free of this malware, per LiteLLM — pin 1.106.2 (or 1.106.5 or later if your proxy runs with an Enterprise license; see the October 27 advisory). Don't start Python on the host until the backdoor files are gone, because every interpreter start re-runs the payload.

Sources re-checked 2026-10-25 ~15:40 UTC (10:40 AM CT): LiteLLM's root-cause analysis (published October 23, 2026, which LiteLLM calls "the canonical source of truth"); the original LiteLLM incident post (status: "Incident contained"; last updated October 21, 2026 20:30 UTC / 3:30 PM CT, with an October 23, 21:50 UTC / 4:50 PM CT note that some of its assumptions "were later discovered to be inaccurate or incomplete"); SafeDep's analysis; the OSV advisory MAL-2026-2144; and LiteLLM's GitHub release notes.

Separate issue, Oct 27: if you run LiteLLM Enterprise, see the master-key advisory — a critical bug fixed in 1.103.10, 1.104.8, 1.105.6 and 1.106.5. It is not the 1.107.0 compromise covered below.

What happened on October 21, 2026

LiteLLM's release pipeline was compromised and pushed v1.107.0 to PyPI and the Docker registries. That release contained compiled malware: a credential stealer and remote-code-execution infrastructure. All previous versions are safe, the impacted releases have been pulled from PyPI, Docker Hub and GHCR, and enterprise customers pulling from LiteLLM's private registry were not affected, per LiteLLM. That registry is also distributing an embargoed release that fixes a vulnerability whose disclosure LiteLLM has scheduled for October 27.

Compromise windows (all times October 21, 2026):

Registry Artifact Window (UTC) Window (CT)
PyPI litellm==1.107.0 11:39 – 13:23 6:39 AM – 8:23 AM
Docker Hub v1.107.0, latest, main-latest, main-stable → index digest sha256:1bbcb1443bc962e45f5aad53fe3d2c30600e0379715fb6c664cdd3ac126c339e 11:46 – 14:20 6:46 AM – 9:20 AM
GHCR compromised from 11:46, unavailable by 13:51 11:46 – 13:51 6:46 AM – 8:51 AM

How it got in, per LiteLLM's October 23 root-cause analysis: on May 27, 2026, a config file committed to the public LiteLLM-Labs/lite-harness repository exposed the master key to a deployment of the LiteLLM Agent Platform, and that key was never revoked. On October 10 the attacker used it to pull a GitHub organization owner's GitHub CLI OAuth token from the platform's API, then ran throwaway CI workflows that posted two maintainers' GitHub CLI tokens to an attacker endpoint. On October 21 the owner's token overrode branch protection and pointed the release workflow at the lookalike repository Berri-AI/litellm, a second maintainer's token approved the production release, and a third deleted the workflow run records. The official v1.107.0 source tag on GitHub does not contain the malicious files. LiteLLM's first post suspected the tokens came from the logs of an internal LiteLLM deployment; the October 23 analysis says the first token came from a different service. LiteLLM says it is revoking every token associated with every internal system and vendor platform.

Attack timeline (UTC from LiteLLM's root-cause analysis; CT added):

When (UTC) When (CT) Event
May 27, 18:53 May 27, 1:53 PM Config file with the Agent Platform master key committed to a public repo
Oct 10, 21:27 Oct 10, 4:27 PM Agent Platform API returns the org owner's GitHub CLI token
Oct 10, 22:11 – 22:12 Oct 10, 5:11 – 5:12 PM Throwaway workflows post two maintainers' tokens to an attacker endpoint
Oct 21, 10:08 Oct 21, 5:08 AM Owner's token overrides branch protection on the release workflow
Oct 21, 11:11 Oct 21, 6:11 AM Second maintainer's token approves the production release
Oct 21, 11:39 – 11:40 Oct 21, 6:39 – 6:40 AM Seven malicious litellm==1.107.0 wheels published to PyPI
Oct 21, 11:46 Oct 21, 6:46 AM Malicious Docker Hub and GHCR images published
Oct 21, 11:53 – 11:54 Oct 21, 6:53 – 6:54 AM Third maintainer's token deletes the release run records
Oct 21, 12:06 Oct 21, 7:06 AM LidorMachluf opens GitHub issue #47826 identifying the compromise
Oct 21, by 13:23 Oct 21, by 8:23 AM PyPI quarantines litellm==1.107.0
Oct 21, by 13:51 Oct 21, by 8:51 AM Affected GHCR tags unavailable
Oct 21, 14:20 Oct 21, 9:20 AM Docker Hub tags removed or repointed to clean images

LiteLLM had hardened its release process after a March 2026 incident, but earlier that week it had temporarily relaxed the rule that a device-locked account in its office approves each release, allowing any two engineers to trigger and approve one. The practical takeaway appears later in this post: trusted publishing and signed images raise the bar, but they don't remove the need for version pins and credential rotation.

Am I affected? Check without starting Python

Order matters: the payload runs in any Python process that starts on the host — including pip itself and processes that never import litellm — so don't run Python until you've checked the filesystem.

(a) Lockfiles and requirements. Search your projects for litellm==1.107.0, or an unpinned litellm requirement that resolved on October 21:

grep -rn "1.107.0" requirements*.txt Pipfile.lock poetry.lock uv.lock 2>/dev/null

(b) Filesystem. Look in site-packages for litellm-1.107.0.dist-info, cook.pth, cook.py, and sitecustomize.py, plus the drop files in /tmp:

find / -name "litellm-1.107.0.dist-info" 2>/dev/null
find / -path "*/site-packages/cook.pth" -o -path "*/site-packages/cook.py" -o -path "*/site-packages/sitecustomize.py" 2>/dev/null
ls -la /tmp/.pc_once_72129118c59f5636c0bb /tmp/remote_code_loader.lock 2>/dev/null

(c) Processes. Look for a detached Python daemon: parent PID 1, its own session, working directory / (this is the hourly re-loader SafeDep describes).

ps -eo pid,ppid,sid,cmd | awk '$2 == 1 && /python/'

(d) Containers. If you pull litellm images, compare what you ran against the bad digests — sha256:1bbcb144… for litellm/Docker Hub tags, and the truncated GHCR digests in the IOC table below. Check whether a container was started from one of those images in the window, not merely pulled:

docker images --digests | grep litellm
docker ps -a --filter "ancestor=ghcr.io/berriai/litellm" --format "{{.ID}} {{.Image}} {{.CreatedAt}}"

(e) pip show litellm — LiteLLM's own check. Note this starts Python, so run it only on a host you're already treating as compromised:

pip show litellm

Rule of thumb, from LiteLLM: if you ran pip install on 1.107.0 or started a Docker image in the compromised interval, assume it's compromised. Finding a marker confirms exposure; not finding one proves nothing.

IOCs as published

All IOCs below are copied verbatim from the sources (defanged where the source defanged them). The GHCR digests are published only in truncated form — don't try to complete them; compare prefixes.

Indicator Source Notes
cook.pth — SHA-256 7f191632e7320705d154b85204f1ae546b543acbd7e8861229b76f5042b92bdb SafeDep / OSV .pth file; import cook runs at every interpreter start
cook.py — SHA-256 9dd0a3926f96a37eb86cf1ee2310d9be93139cc4ebef3ef9e2efe9531390be25 SafeDep / OSV credential stealer ("privcollect")
sitecustomize.py — SHA-256 34bef04fe88ac9d0aae0475630b1738681d15b94f233ac8aa46eacf5968305fa SafeDep / OSV hourly remote-code loader daemon
/tmp/.pc_once_72129118c59f5636c0bb SafeDep / OSV marker written after the stealer's first run
/tmp/remote_code_loader.lock SafeDep lock file of the backdoor daemon
PRIVCOLLECT_ACTIVE=1 env var SafeDep present in infected processes
www.litellm[.]dev/healthcheck SafeDep / OSV exfiltration endpoint
X-Token: XWiA8gZNa7NcX2XRoAEb SafeDep HTTP header sent with exfil
raw.githubusercontent[.]com/letters9813/pythonclient-test/main/domain.txt SafeDep / OSV backdoor reads its server address here
Berri-AI/litellm lookalike repo LiteLLM the compromised artifacts were built from an attacker-controlled repo
Docker index digest sha256:1bbcb1443bc962e45f5aad53fe3d2c30600e0379715fb6c664cdd3ac126c339e LiteLLM Docker Hub tags v1.107.0, latest, main-latest, main-stable
ghcr.io/berriai/litellm sha256:1bbcb1443bc9… LiteLLM truncated, as published
ghcr.io/berriai/litellm-database sha256:c00f9d92c427… LiteLLM truncated, as published
ghcr.io/berriai/litellm-non_root sha256:7b00e91cd2fe… LiteLLM truncated, as published
IP 69.48.229.143 LiteLLM (Oct 23 analysis) Agent Platform API requests, October 10
IP 199.91.221.39 LiteLLM (Oct 23 analysis) release-repo pushes and the production approval, October 21
Fork commit 20535d8fa11f786a6c24df7488a0e449ed5f09ad LiteLLM Berri-AI/litellm commit the malicious release was built from

SafeDep's page also publishes SHA-256 hashes for the sdist and all seven 1.107.0 wheels — link to their table rather than retyping them here. The three planted-file hashes above are the Linux and macOS values; on Windows the files hash differently because of CRLF line endings, and SafeDep lists those too. LiteLLM's root-cause analysis lists further indicators inside its own GitHub organization (workflow commits and exfiltration branches).

Caveat: the same OSV entry (MAL-2026-2144) also covers the March 2026 1.82.7/1.82.8 releases, and its litellm.cloud / models.litellm.cloud IOC block is from that March incident — not October.

Clean up first, in this order (LiteLLM's steps)

LiteLLM's remediation guidance, in their order:

  1. Delete the backdoor files from the shell, not from Python: cook.pth, cook.py, sitecustomize.py, and the matching __pycache__/cook*.pyc and sitecustomize*.pyc.
  2. Kill the daemon holding /tmp/remote_code_loader.lock.
  3. Reinstall pinned to 1.106.2 (1.106.5 or later on an Enterprise-licensed proxy; see the October 27 advisory). Rebuilding the host or image from a clean base is better.
  4. Assume exfiltration succeeded if 1.107.0 was ever installed on a host with outbound internet. If the marker file /tmp/.pc_once_72129118c59f5636c0bb exists, the exfil is confirmed; if it doesn't, that proves nothing — containers and tmp cleanup remove it.

Only after the files are gone and the daemon is dead is it safe to run Python tooling on the host again.

Rotate in this order

Steps 1–3 below follow LiteLLM's remediation list; the overall ordering and steps 4–6 are Tacavar's recommendation, based on what SafeDep and OSV document the stealer collecting.

  1. The instance/task IAM role, plus cloud CLI credentials. The stealer queries the AWS instance metadata service (169.254.169.254, and 169.254.170.2 per OSV) and collects ~/.aws, Azure and gcloud credentials. If this host had rights over other machines, treat those machines as in scope for the rotation too.
  2. Every LLM provider key in the LiteLLM proxy database, plus the LiteLLM master key and virtual keys — the stealer reads DATABASE_URL and dumps the LiteLLM_CredentialsTable and LiteLLM_ProxyModelTable tables.
  3. The DATABASE_URL password itself, and every secret in any process environment on the host — the stealer reads other processes' environment via /proc.
  4. GitHub and CI/CD tokens: gh hosts.yml, .git-credentials, GitLab runner, Jenkins, Vault, Terraform, plus package-registry tokens (.pypirc, .npmrc). A stolen token is how this attack started — rotating SSH keys is not enough if your access model still leans on shared credentials; we wrote up a two-servers, no-shared-SSH-keys setup that removes that dependency.
  5. kube configs and k8s service-account tokens, SSH, GPG and TLS keys.
  6. AI dev-tool tokens (Claude Code, Claude Desktop, Cursor, Windsurf, Copilot, Gemini CLI, Codex auth.json, Hugging Face, VS Code mcp.json and other MCP config secrets) and browser-saved passwords.

Then hunt: LiteLLM's guidance says to check CloudTrail for GetCallerIdentity calls from the instance role around install time, then for use of the role's credentials from outside your infrastructure.

For the per-provider revoke and spend-limit steps, see how to respond to leaked AI API keys — that guide covers one provider at a time; this one covers a host that took every key at once.

Prevent the next one

  • Pin exact versions (litellm==1.106.2, not litellm or >=), and install with hash checking: pip install --require-hashes (pip docs).
  • Pin container images by digest, not tag (docker pull reference). Tags move; digests don't.
  • Use PyPI Trusted Publishing for packages you publish (docs) — but be honest about its limits: LiteLLM had hardened its pipeline after March, and this still got through. Trusted publishing is not sufficient alone.
  • Don't let "latest" auto-update in production. latest was one of the four compromised Docker tags. The same goes for editor extensions: on October 29 a backdoored Claude Code extension reached Cursor users as an auto-update — see the separate Oct 29 incident below.
  • Revoke exposed keys immediately, and don't give automation a person's owner-level token. Per LiteLLM's root-cause analysis, the chain started with a master key committed to a public repository in May that was never revoked, and the GitHub token it exposed was an org owner's GitHub CLI OAuth token that "was not associated with a service account and was not scoped down." LiteLLM also notes that GitHub CLI tokens are post-2FA and not subject to GitHub's re-authentication prompts for sensitive organization actions. Give bots and CI scoped service credentials instead. (LiteLLM's original incident post also described cases where Claude Code can embed a user's GitHub CLI OAuth token in a response body that may then be logged; its October 23 analysis says the first token did not come from those logs, but it is still a reason to keep secrets out of LLM-proxy logs and keep those logs off the public internet.)
  • Govern MCP-style tool access explicitly. The stealer specifically harvests AI dev-tool tokens and mcp.json secrets; our guide to MCP tool governance in production covers how to scope what an agent — and anything that compromises it — can reach.
  • Put a firewall in front of agent actions, so a compromised process can't silently exfiltrate credentials or call arbitrary endpoints; see agent firewall: production governance.
  • Give the proxy host a narrow IAM role, so a host compromise can't walk into your whole cloud account — and if you're weighing self-hosting the proxy at all, self-hosted AI sovereignty covers the trade-offs.
  • Harden anything that went from prototype to production without a security pass — the vibe-coded production hardening checklist is a starting point for exactly the kind of host this attack lands on.

This is the core of what we do at Tacavar — governed agent operations, where credential blast radius is designed in before an incident, not discovered after one. Ask about Governed AI Ops if you want help getting there.

Separate Oct 27 advisory: LiteLLM Enterprise proxy master-key leak (GHSA-w4c7)

Running a LiteLLM proxy with an Enterprise license below 1.103.10, 1.104.8, 1.105.6 or 1.106.5 (per release line)? One unauthenticated request can make it send a local file's contents — LITELLM_MASTER_KEY and provider API keys included — to an attacker. In some configurations, LiteLLM says, that leads to arbitrary Python code execution as root. LiteLLM rates it Critical, CVSS 10.0. Open-source installs without a license are not affected, per LiteLLM's advisory. Patch, then rotate.

This is not the 1.107.0 compromise

The 1.107.0 incident was a poisoned release: a supply-chain attack you avoid by never installing the compromised build. GHSA-w4c7-34wj-hqm8 is a bug inside LiteLLM's own legitimate releases, and it only activates on proxies running with an Enterprise license. The two are independent: an install that is clean of 1.107.0 can still be exposed to this, and vice versa. The thread connecting them is the one this page keeps returning to — whoever holds the master key holds the whole proxy.

Am I affected?

Work down this checklist, in order:

  1. Is an Enterprise license active on the proxy? LiteLLM's advisory is explicit: open-source deployments without a license are not affected, because the vulnerable code paths only load when an Enterprise license is active.
  2. Which version are you on? Compare against the fixed version on your release line — 1.103.10, 1.104.8, 1.105.6, or 1.106.5. Anything below the fix on your line is in scope, per the advisory.
  3. Can untrusted traffic reach the proxy? The attack is an unauthenticated request to any LLM route, so an internet-reachable proxy is the worst case.
  4. Where does the master key live? If LITELLM_MASTER_KEY or provider keys are in the process environment, reading /proc/self/environ yields them, which is the disclosure path LiteLLM describes. A secret manager is LiteLLM's defense-in-depth advice, not a reason to skip patching: the bug can read any local file.

The advisory publishes no log signature, so don't assume you could confirm or rule out access from logs alone. One generic hygiene step — Tacavar's suggestion, not LiteLLM's — is to review egress and proxy logs for unexpected outbound POSTs to unfamiliar endpoints.

Can't patch today? Do these three things

LiteLLM's advisory lists mitigations for teams that cannot update immediately:

  1. Block the trigger at the edge. Add a WAF, ingress filter, or reverse-proxy rule that rejects or strips POST request bodies containing any of these JSON keys: standard_callback_dynamic_params, gcs_path_service_account, callbacks, success_callback, failure_callback. (Tacavar's note, not LiteLLM's: some legitimate clients may send these keys, so test the rule against real traffic first.)
  2. Egress-allowlist the proxy. The exploit has to POST the stolen file contents to an attacker-controlled token endpoint. If the proxy's outbound access is restricted to your configured LLM provider endpoints, the exfiltration fails even if the vulnerable code is reached.
  3. Take the proxy off the public internet. LiteLLM generally recommends keeping it behind a VPN, mTLS, an authenticating ingress, or an IP allowlist.

After patching: rotate and harden

If an Enterprise-licensed proxy was reachable on an affected version, treat the master key and your provider API keys as exposed and rotate them — use the "Rotate in this order" checklist above, and the broader key-rotation playbook in Which AI API keys leak, and what to do about it. Then harden so the next advisory is boring: load the master key from a secret manager instead of the process environment, set a separate LITELLM_SALT_KEY, and keep outbound traffic limited to known provider endpoints — all recommendations from LiteLLM's own advisory.

Egress allowlists, secrets out of env, and a schedule that actually re-checks them are the governance layer we run for agent stacks. Ask about Governed AI Ops.

Separate Oct 29 incident: backdoored Claude Code extension 2.1.312/2.1.313 in Cursor (svc-telemetry SSH key)

This is not the 1.107.0 compromise — a different incident that came through an IDE extension marketplace, not PyPI or Docker. Same lesson.

If Cursor installed or auto-updated the Claude Code extension to 2.1.312 or 2.1.313 on macOS or Windows between about 2:27 AM and 1:35 PM PT on October 29, 2026, check ~/.ssh/authorized_keys for a key labeled svc-telemetry before uninstalling. Uninstalling is not enough, per Cursor's notice: persistence keeps running. Install 2.1.314 or later, then rotate credentials from a clean machine.

What happened

Per Cursor's notice, maliciously modified macOS and Windows builds of anthropic.claude-code 2.1.312 and 2.1.313 — not developed by Anthropic — were in Cursor's extension marketplace between about 2:27 AM and 1:35 PM PT on October 29, 2026. Cursor initially said at most 5,000 users were affected (as reported by The Hacker News); the updated notice gives no count. The loader is 66 lines inserted before the legitimate code in extension.js (OpenSourceMalware, via The Hacker News); it runs as soon as the extension loads, no conversation needed (StepSecurity). Per Cursor, it collects host details (including environment variable names), adds an attacker SSH key, installs persistence, tries to open a reverse tunnel, retrying roughly every 60 seconds, and beacons to port 8099. Cursor pulled the version, confirmed no other extensions were tampered with, and rotated its keys.

Which channel and which versions: reports conflict. Cursor's notice covers its own marketplace and, since its October 30 update, names 2.1.312 as well as 2.1.313. StepSecurity says 2.1.313 was published to Open VSX and mirrored by Cursor, and found the Open VSX 2.1.312 and 2.1.314 builds clean. The Hacker News' corrected report traces the incident to Cursor's marketplace, with no evidence it reached Open VSX or Microsoft's Marketplace. On Cursor, treat 2.1.312 as affected; on an Open VSX editor, run the check anyway. How it got published is not established.

Am I affected? Check the key before you touch the extension

The malicious extension appends the attacker's public SSH key, labeled svc-telemetry, to your SSH authorized keys. Run the check from Cursor's notice — on macOS:

grep -qs svc-telemetry ~/.ssh/authorized_keys && echo "svc-telemetry key found" || echo "No key found; machine not impacted"

On Windows, in PowerShell:

$files = "$HOME\.ssh\authorized_keys", "C:\ProgramData\ssh\administrators_authorized_keys" | Where-Object { Test-Path $_ }
if ($files -and (Select-String svc-telemetry $files)) { "svc-telemetry key found" } else { "No key found; machine not impacted" }

A key comment is just text, so also hunt by fingerprint: SHA256:0Z6R+DF64Do2nwQic8a7kkfDLNNk4IiK+2U2Rci4htk (Cursor's published IOC — match it with ssh-keygen -lf). Then look for anthropic.claude-code 2.1.312 or 2.1.313 in your editor's extension list; per Cursor, the bad builds' extension.js contains svc-telemetry.

Check before uninstalling: removal deletes the easiest evidence for scoping. If the check hits, isolate the host and preserve evidence before cleaning.

Is uninstalling enough? No

Per Cursor: "Uninstalling the extension may not be sufficient — the payload drops standalone persistence scripts that keep running." What survives removal, from Cursor's IOC list:

  • macOS: LaunchAgent com.apple.sysmond; files ~/.config/.smt, ~/.config/.smtk, $TMPDIR/.stk_*.
  • Windows: scheduled task SysMon (attempts SYSTEM), Startup sysmon.cmd fallback; files %USERPROFILE%\.config\smt.cmd, %USERPROFILE%\.config\smtk, %TEMP%\.stk_*.
  • Linux (in Cursor's IOC list, outside its stated macOS/Windows scope): cron @reboot /bin/sh "<HOME>/.config/.smt"; files ~/.config/.smt, ~/.config/.smtk, /tmp/.stk_*.

Background scripts keep retrying the reverse tunnel (ssh -N -R / autossh -M 0, per Cursor). Order: if the key is found, isolate and preserve evidence; run Cursor's remediation scripts (macOS as the affected user, not root; Windows from an elevated PowerShell); on Linux, which the scripts don't cover, remove the key, cron entry and dropped files by hand; then install 2.1.314 or later; then rotate.

What could the attacker actually do?

Honest limits, per Cursor: enabling the local SSH service requires admin rights, which the extension lacks on most macOS and Windows hosts — there the step fails and the attacker could not log in through the tunnel. The attacker's server was taken offline, so the tunnel and beacon no longer work. But affected hosts still got the attacker's SSH key, persistence, and host details — including names of up to 40 environment variables matching KEY, TOKEN, SECRET, PASS, AWS or GCP (The Hacker News). Names are not values, but they can reveal which credential types are configured (Paul McCarty, via The Hacker News). Cursor says to remediate regardless: the limited env-var collection does not rule out later credential access. If the tunnel is confirmed to have connected, rebuilding is safer than cleaning (StepSecurity). Contact: security@cursor.com.

Rotate, then fix the channel

Rotate with this page's "Rotate in this order" checklist, plus SSH: remove the svc-telemetry key and review other authorized-keys entries; rotate source-control, CI/CD, cloud, and package-registry tokens from a known-clean machine (Cursor; StepSecurity) — the fuller playbook is in Which AI API keys leak, and what to do about it.

Then fix the channel — the LiteLLM lesson again: a trusted, auto-updating distribution — latest there, an IDE marketplace auto-update here — shipped a backdoor under the real publisher's name. Pin or delay extension auto-updates on machines holding production credentials, inventory extension versions so "who has 2.1.312 or 2.1.313?" is one query, and keep SSH and production keys off developer laptops — see Two servers, no shared SSH keys.

Knowing which dev tools, at which versions, hold which credentials across a team — and having the rotation order written before the next incident — is the governance layer we run for AI-heavy teams. Ask about Governed AI Ops.

FAQ

Was LiteLLM hacked? Which versions are affected? Yes. On October 21, 2026, LiteLLM's release pipeline was compromised and pushed v1.107.0 to PyPI, Docker Hub and GHCR with a credential stealer and backdoor inside. Only litellm==1.107.0 (PyPI) and the v1.107.0, latest, main-latest and main-stable Docker tags are affected; the official GitHub source tag is clean, all previous versions are safe per LiteLLM, and enterprise private-registry users were not affected. The compromised artifacts have been removed from the registries.

How do I know if I installed the malicious LiteLLM 1.107.0? Check, in order and without starting Python: your lockfiles for 1.107.0, site-packages for cook.pth / cook.py / sitecustomize.py and litellm-1.107.0.dist-info, /tmp for .pc_once_72129118c59f5636c0bb and remote_code_loader.lock, running processes for a detached Python daemon with PPID 1, and your container image digests against the IOCs above. LiteLLM's rule: if you installed or ran 1.107.0 in the window, assume compromised regardless of what the checks show.

Is it safe to run pip show litellm to check? It's LiteLLM's own suggested check, but it starts Python — and any Python start on an infected host re-runs the payload. Run it only on a host you're already treating as compromised, after the cleanup steps, or not at all; the filesystem checks above don't need Python.

I only pulled litellm:latest from Docker. Am I affected? If you pulled or started latest between 11:46 and 14:20 UTC (6:46 – 9:20 AM CT) on October 21, 2026, yes — latest pointed at the same compromised image digest as v1.107.0 (sha256:1bbcb144…). Check whether the container was actually started from it, then rotate credentials. A pull that never ran is lower risk, but treat a started container as a compromised host.

Which LiteLLM version is safe to pin? For the 1.107.0 compromise, 1.106.2: LiteLLM's guidance is to pin to 1.106.2 or any explicit version published before the incident. If your proxy runs with an Enterprise license, pin 1.106.5 or later instead, because 1.106.2 is below the fix in LiteLLM's October 27 advisory GHSA-w4c7-34wj-hqm8. SafeDep also confirms 1.107.0rc1, 1.107.0rc2, litellm-proxy-extras==0.4.110 and litellm-enterprise==0.1.78 are clean. LiteLLM has since published 1.106.3 (October 24) and 1.106.4 (October 25). Starting with 1.106.3, its Docker images and Helm charts are signed with a new cosign key (commit e82a3c6), and verifying with the old key fails, so update any cosign verify scripts or admission policies.

What credentials should I rotate first after the LiteLLM compromise? Cloud instance-role and cloud CLI credentials, then the LLM provider keys in the LiteLLM proxy database (plus master and virtual keys), then the DATABASE_URL password and host-wide process environments, then GitHub / CI-CD / registry tokens, then kube / SSH / GPG / TLS keys, then AI dev-tool tokens and browser passwords. Steps 1–3 follow LiteLLM's list; the full ordering is Tacavar's recommendation. Then hunt for anomalous GetCallerIdentity and off-infrastructure use of the instance role.

Does removing the files make the host clean? No. Deleting cook.pth, cook.py and sitecustomize.py and killing the daemon stops the bleeding, but the stealer uploads on its first run, and the backdoor daemon re-runs an embedded copy of the stealer every hour and could fetch and run second-stage code (per SafeDep). If it executed, assume it uploaded, and rotate everything. A rebuild from a clean image is safer than an in-place cleanup.

Doesn't trusted publishing prevent this? It helps, but it didn't here. LiteLLM had release hardening in place after the March 2026 incident, but the attacker held stolen GitHub CLI tokens for an org owner and two maintainers, used the owner's token to override branch protection, and passed the release approval with a second token while that approval rule was temporarily relaxed. The official pipeline then signed and published the artifacts. Trusted publishing removes one path; hash-pinned installs and digest-pinned images remove your dependence on the registry being right.

Is open-source LiteLLM affected by GHSA-w4c7-34wj-hqm8? No. LiteLLM's advisory says open-source deployments without a license are not affected, because the vulnerable code paths only load when an Enterprise license is active.

Which LiteLLM versions fix the Enterprise master-key leak? 1.103.10, 1.104.8, 1.105.6 and 1.106.5. Versions below those on each release line are affected, per LiteLLM's Oct 27, 2026 advisory.

How do I protect a LiteLLM Enterprise proxy if I can't update yet? LiteLLM recommends blocking POST bodies containing standard_callback_dynamic_params, gcs_path_service_account, callbacks, success_callback or failure_callback at the edge, restricting outbound traffic to your LLM provider endpoints, and keeping the proxy off the public internet.

Was the Claude Code extension in Cursor hacked? Yes. Modified macOS and Windows builds of anthropic.claude-code 2.1.312 and 2.1.313, not built by Anthropic, were in Cursor's extension marketplace from about 2:27 AM to 1:35 PM PT on October 29, 2026, per Cursor, which initially said at most 5,000 users were affected. They planted an SSH key labeled svc-telemetry and persistence. Version 2.1.314 is clean, per StepSecurity.

How do I check if I got the malicious Claude Code extension? Search your SSH authorized_keys file for svc-telemetry — Cursor publishes one-line checks for macOS and Windows — and also match the key fingerprint SHA256:0Z6R+DF64Do2nwQic8a7kkfDLNNk4IiK+2U2Rci4htk. A match means the machine is affected. Check before uninstalling, so you don't remove the evidence.

Is uninstalling the Claude Code extension enough? No. Cursor says the payload drops standalone persistence scripts that keep running after the extension is removed. Remove the key, the LaunchAgent, scheduled task or cron entry, and the dropped files (Cursor's scripts cover macOS and Windows), update to 2.1.314 or later, and rotate credentials from a clean machine.

If you're running LiteLLM (or any LLM proxy) in production and want this class of blast-radius problem designed out — pinned artifacts, narrow IAM, token governance, rotation drills — ask about Governed AI Ops. For a quick read on your current exposure, start with our scan.

Related Reading