LiteLLM supply chain attack via unrevoked key compromises 49k users with credential stealer

1. Executive summary

LiteLLM, an open-source AI gateway with roughly 23 million weekly downloads, published version 1.107.0 to PyPI and Docker on 21 October 2026 carrying a credential stealer and a remote access trojan; the package was downloaded about 49,000 times before removal. The root cause was a master key for an internal LiteLLM agent platform committed to a public GitHub repository on 27 May 2026 and never revoked, which let an unidentified attacker reach an internet-exposed internal deployment, lift GitHub CLI OAuth tokens from its logs, and drive three engineer accounts to alter the release pipeline. Wiz observed stolen AWS credentials being tested against Amazon Bedrock models about four and a half hours after exfiltration, consistent with LLMjacking. No CVE is associated with this item and no CISA KEV entry applies; the risk is to any EMEA financial services firm running LiteLLM in developer, CI or proxy environments, where the malware executes on every Python start regardless of whether LiteLLM is invoked. Attribution to TeamPCP is not established for this incident.

2. Regulatory framing

3. Technical analysis & attack chain

1. On 27 May 2026 a configuration file was committed to the public LiteLLM-Labs/lite-harness repository containing the master key to a deployment of LiteLLM's internal agent platform. LiteLLM removed the file but did not revoke the key.
2. Earlier in October 2026 an attacker used the still-valid master key to reach an internal LiteLLM deployment exposed to the public internet. LiteLLM found an unexpected, innocuously named user account in that deployment and believes the attacker gained access through it. How the attacker first reached the deployment is unconfirmed; LiteLLM suspects a recently patched vulnerability.
3. The attacker recovered GitHub CLI OAuth tokens from the deployment's logs. LiteLLM states that Claude Code embeds a user's GitHub CLI OAuth token into a response body in specific circumstances, so where response bodies are logged those tokens appear in LiteLLM logs.
4. With GitHub CLI credentials for three engineer accounts, the attacker disabled branch protections, merged a change pointing the releaser at a different source repository, and ran a compromised GitHub workflow. One account changed the release pipeline and triggered the release, a second approved it, and a third deleted the workflow records, limiting the logs available to investigators.
5. The workflow built from Berri-AI/litellm, a hyphenated lookalike of the legitimate BerriAI/litellm organisation, and signed and published the poisoned artefacts. Version 1.107.0 reached PyPI at 11:39 UTC and was quarantined at 13:23 UTC. Docker images tagged v1.107.0, latest, main-latest and main-stable served the bad build from 11:46 to 14:20 UTC on Docker Hub and GHCR.
6. The payload drops three files into the site-packages root: cook.pth, cook.py and sitecustomize.py. cook.pth causes cook.py to run on every Python interpreter start, whether or not the application loads LiteLLM. cook.py is the infostealer; sitecustomize.py is the RAT, which spawns a background daemon polling attacker infrastructure hourly for Python to execute.
7. The stealer covers 16 collection modules: browser credentials and cookies from Chrome, Firefox, Edge and Safari; AWS credentials from ~/.aws/ and EC2/ECS instance metadata (IMDS); environment variables; GCP service account keys and application default credentials; Azure tokens from the CLI cache; API keys for OpenAI, Anthropic, Cohere and other LLM providers; SSH private keys; GPG keys; shell history; Git credentials; Kubernetes and Docker credentials; saved browser logins, cookies and browsing history; and authentication files for Codex, Claude, Gemini and Cursor. It also attempts to pull stored credentials and model settings from the database of LiteLLM proxy deployments.
8. Stolen data is encrypted with AES-256-CBC, the encryption key wrapped with an RSA-4096 public key, and posted over HTTP to http://www[.]litellm[.]dev/healthcheck. The RAT also checks a GitHub dead drop hourly and runs whatever Python the attacker serves.
9. Wiz observed the attacker testing stolen AWS credentials against Amazon Bedrock models about four and a half hours after exfiltration, matching the LLMjacking pattern in which an intruder runs AI workloads on the victim's account and leaves the victim with the bill. No affected organisation has publicly confirmed a breach linked to the release.

LiteLLM states its enterprise customers pulling from its private registry were not affected, and that all versions before 1.107.0 are safe. The most recent clean version is 1.106.2. Updating is not sufficient on its own: anyone who installed 1.107.0 before removal should treat every credential the host could reach as compromised.

Attribution is unconfirmed. The March 2026 LiteLLM compromise was later linked to TeamPCP (MITRE G1056) and Australian police have charged two men alleged to be members, but no source ties TeamPCP to the October incident, and the October actor is described only as unidentified. The 49,000 download figure and the four-and-a-half-hour credential-testing timeline are Wiz findings; the file-level payload detail rests on Socket, Wiz and Aikido analysis reported by The Register and Help Net Security, and should be treated as single-vendor until independently corroborated.

4. Mitigation & containment

P1, within 24 hours

• Inventory every host, container and CI runner that installed LiteLLM 1.107.0 or pulled litellm/litellm under the tags 1.107.0, latest, main-latest or main-stable between 11:39 and 14:20 UTC on 21 October 2026. Check package manifests, lockfiles and image digests, not just the running version.
• On any confirmed or suspected host, check for /tmp/.pc_once_* (exfiltration has already run if present) and /tmp/remote_code_loader.lock (the C2 daemon ran or is still running if present). Isolate the host from the network before cleaning.
• Rotate every credential the host could reach: AWS keys and instance role sessions, Azure CLI tokens, GCP service account keys and application default credentials, Kubernetes and Docker registry credentials, Git credentials, SSH private keys, GPG keys, and API keys for OpenAI, Anthropic, Cohere and other LLM providers. Rotate from a clean machine.
• Review AWS CloudTrail for Bedrock model invocations and credential use from unfamiliar source addresses in the window from 21 October onward, and check Azure and GCP equivalents for the same.
• Block egress to litellm[.]dev at proxy and DNS. The exfiltration endpoint is www[.]litellm[.]dev/healthcheck over HTTP.

P2, within 72 hours

• Pin LiteLLM to 1.106.2 or later clean releases and remove 1.107.0 from internal mirrors and registries. Verify image provenance against the legitimate BerriAI organisation; reject any artefact whose build record names Berri-AI/litellm.
• Audit GitHub organisation settings for the tokens LiteLLM reported stolen: review branch protection changes, workflow edits and deleted workflow runs on any repository where LiteLLM tooling or its CI patterns are used.
• Search LiteLLM proxy and gateway logs for GitHub CLI OAuth tokens in logged response bodies, and disable response-body logging where it is not required.
• Hunt for the three dropped files, cook.pth, cook.py and sitecustomize.py, in site-packages directories across developer endpoints and build agents.

P3, within 7 days

• Add the YARA and Sigma rules in section 6 to endpoint and CI scanning.
• Review whether AI gateway tooling is permitted to run with production cloud identities, and move it to scoped, short-lived credentials.
• Require revocation, not just removal, when secrets are found in public repositories; the May exposure was detected and the file deleted, and the key stayed valid for five months.

5. Indicators of compromise

domain  litellm[.]dev
url  hxxp://www[.]litellm[.]dev/healthcheck
filepath  /tmp/.pc_once_*
filepath  /tmp/remote_code_loader.lock
filename  cook.pth
filename  cook.py
filename  sitecustomize.py
package  litellm==1.107.0
container  litellm/litellm:1.107.0
container_tag  latest
container_tag  main-latest
container_tag  main-stable
repository  github.com/Berri-AI/litellm

Behavioural indicators

6. Detection

rule LiteLLM_1070_Stealer_RAT
{
    meta:
        author = "Adverse Trace"
        date = "2026-10-26"
        reference = "https://therecord.media/litellm-hackers-ai-malware"
        description = "Detects the cook.py stealer and sitecustomize.py RAT dropped by LiteLLM 1.107.0"
    strings:
        $exfil = "litellm.dev/healthcheck" ascii wide
        $host = "www.litellm.dev" ascii wide
        $pth = "cook.pth" ascii wide
        $loader = "remote_code_loader.lock" ascii wide
        $once = ".pc_once_" ascii wide
        $aws = ".aws/credentials" ascii wide
        $imds = "169.254.169.254" ascii wide
    condition:
        uint32(0) == 0x0a0d0a0d or filesize < 5MB
        and 2 of them
}

title: LiteLLM 1.107.0 Python Startup Persistence and Exfiltration
id: 7c1e4b2a-9f3d-4a61-8e2c-litellm1070
status: experimental
author: Adverse Trace
date: 2026/10/26
references:

  - https://therecord.media/litellm-hackers-ai-malware
  - https://www.theregister.com/security/2026/10/21/litellm-supply-chain-attack-hoovers-up-passwords-and-secrets/5304548
logsource:
  category: process_creation
  product: linux
detection:
  selection_python:
    Image|endswith:

      - '/python'
      - '/python3'
  selection_artefact:
    CommandLine|contains:

      - 'sitecustomize'
      - 'cook.py'
  selection_network:
    DestinationHostname|contains: 'litellm.dev'
  condition: selection_python and (selection_artefact or selection_network)
falsepositives:

  - Legitimate LiteLLM installations resolving the vendor domain before 21 October 2026
level: high

Threat actor context

TeamPCP · G1056 · aka PCPCat, ShellForce, DeadCatx3, SHADOW-WATER-058, UNC6780

TeamPCP is a financially-motivated, cloud-native threat group that has been active since at least September 2025. Initially focused on ransomware and cryptocurrency theft, TeamPCP shifted in early 2026 to systematic, worm-driven credential theft and software supply chain attacks targeting Continuous Integration and Continuous Delivery (CI/CD) workflows. …

7. Sources

• Alexander Martin, The Record, "Popular AI tool LiteLLM says unrevoked key allowed hackers to target users", https://therecord.media/litellm-hackers-ai-malware, 2026-10-26.
• Help Net Security, "LiteLLM hit by second supply chain attack this year, users urged to rotate credentials", https://www.helpnetsecurity.com/2026/10/22/litellm-compromised-supply-chain-attack-pypi-docker/, 2026-10-22.
• The Hacker News, "LiteLLM Suspects GitHub Token Leak in AI Gateway Logs Behind Malicious Package Release", https://thehackernews.com/2026/10/litellm-suspects-github-token-leak-in.html, 2026-10.
• The Hacker News, "Leaked LiteLLM Master Key Let Attackers Steal GitHub Tokens and Hijack Release Pipeline", https://thehackernews.com/2026/10/leaked-litellm-master-key-let-attackers.html, 2026-10.
• SecurityWeek, "LiteLLM Compromised in Fresh Supply Chain Attack", https://www.securityweek.com/litellm-compromised-in-fresh-supply-chain-attack/, 2026-10.
• The Register, "LiteLLM supply chain attack hoovers up passwords and secrets", https://www.theregister.com/security/2026/10/21/litellm-supply-chain-attack-hoovers-up-passwords-and-secrets/5304548, 2026-10-21.
• The Hacker News, "Malicious LiteLLM Releases Tied to Trivy Hack May Have Exposed 2,100+ Organizations", https://thehackernews.com/2026/08/malicious-litellm-releases-tied-to.html, 2026-08.

8. Adverse Trace position

Adverse Trace assesses this as a high-impact supply chain compromise with a narrow but severe exposure window: two hours on PyPI and roughly two and a half hours on Docker, 49,000 downloads, and a payload that runs on every Python start rather than only when LiteLLM is imported. No CVE or CISA KEV entry applies, so severity here is driven by credential exposure and the speed of follow-on abuse, not by a patchable vulnerability score. Attribution to TeamPCP is unconfirmed for this incident and we will not carry it into client reporting until a source ties the actor to the October release; the March campaign is a separate, earlier event. The payload detail and the LLMjacking timeline are single-sourced to Wiz, Socket and Aikido reporting and should be verified against your own telemetry before enforcement. We will track LiteLLM's root-cause analysis and any confirmation of the suspected patched vulnerability behind the initial deployment access, and we will update this advisory if a client-relevant indicator set or attribution emerges. Clients running LiteLLM in CI or proxy roles should complete the P1 credential rotation before treating the incident as closed.

Read the original source →

Published via PulseTrace — Adverse Trace threat intelligence.