LiteLLM 1.107.0 Supply Chain Compromise: Python Startup Hooks Steal Cloud and AI Credentials

1. Basic Information

• Article Title: The attack chain behind the v1.107.0 LiteLLM release
• Publisher: LiteLLM
• Publication Date: 2026-10-23
• Report Update Date: 2026-10-25
• Original Source: The attack chain behind the v1.107.0 LiteLLM release
• Related Sources: Initial Report: Contained: Oct 21, 2026 LiteLLM release v1.107.0 Compromised, BleepingComputer: LiteLLM release pipeline hacked, Socket: LiteLLM PyPI Package and Docker Images Compromised, Endor Labs: LiteLLM 1.107.0 Compromised
• Associated Malware / Threat Groups: cook.pth, cook.py, sitecustomize.py
• Associated CVEs: None
• Affected Products: LiteLLM, PyPI, Docker Hub, GitHub Container Registry
• Severity: Critical
• Basis for Severity: The incident allowed credentials for cloud services, CI/CD, AI providers, browsers, and SSH to be stolen from officially signed and distributed artifacts, while enabling external code execution. The inclusion of malicious code in public artifacts and the malware execution path have been officially confirmed.

2. Executive Summary

The LiteLLM release workflow was compromised, introducing an info-stealer and a remote Python loader into officially signed PyPI wheels and Docker images (v1.107.0). In Python environments where the malicious files are loaded during startup, simply running Python or pip commands triggers the malicious code even without explicitly importing LiteLLM. Official root cause analysis confirmed that an Agent Platform master key exposed in a public repository in May, which was never revoked, served as the initial vector. Note that the presence of collection-suppression environment variables and success markers means that data exfiltration did not necessarily complete in every execution.

Key Updates as of October 25

• On October 23, LiteLLM published a canonical root cause analysis that supersedes previous hypotheses. Attackers used the master key exposed on October 10 to access the Agent Platform API and obtain an unrestricted GitHub CLI OAuth token belonging to an organization owner.
• Using the owner token, they executed a temporary workflow to exfiltrate two maintainer tokens and additional secrets. They then used the owner token to trigger a staging workflow, approved the production gate with one maintainer token, and deleted the release run logs using the other maintainer token. Although main was reverted and force-pushed to restore history, the audit logs and commit SHAs remain as evidence.

3. Attack Chain

Attack and Exploitation Chain Reconstructed from Public Information

1. Attackers used an Agent Platform master key that was accidentally committed to a public repository in May 2026 and never revoked. On October 10, they obtained an unrestricted GitHub CLI OAuth token for an organization owner via the Agent Platform API, and used that token to run a temporary workflow that additionally stole two maintainer tokens and other secrets.
2. The attackers abused repository owner privileges to disable branch protection rules and redirect the release workflow source reference to a malicious repository (Berri-AI/litellm).
3. They published official wheel packages and container images containing malicious code through PyPI's Trusted Publisher and legitimate signing and build channels.
4. Python startup hooks (.pth / sitecustomize) in victim environments automatically executed the malicious script, harvested and exfiltrated credentials, while a background loader fetched and executed additional code from external sources.

The table below organizes the public information above, with identifiers serving as candidate checks for internal investigation (Inference). Specific implementations and subsequent actions that remain private are not extrapolated.

4. Attacker Position and Execution Location

• A remote attacker holding stolen GitHub credentials with permissions to manipulate the LiteLLM release repository and workflows.

5. Victim and Administrator Perspective

Victims

• Packages introduced as legitimate distributions via standard pip install or docker pull, with malware executing in the background upon Python execution.

Administrators and SOC

• Observable via affected package versions, container image digests, Python startup files (.pth), suspicious external communications, and anomalous access in cloud audit logs.

6. Success and Failure Conditions

Success Conditions

• Introduction of a malicious wheel or affected container image, executed in an environment where its Python startup hooks are loaded (distinguishing clearly between mere download/pull and actual execution).
• Residual artifacts may remain in local caches, mirrors, and saved images even after public pull-down. Persistence is not strictly required for all attacks; verify the exact running digest and installed files rather than relying solely on tag names.
• Successful credential theft requires target secrets to be readable by the executing process and network reachability to the exfiltration destination (distinguishing between hook execution, data collection, and external transmission success).

Failure Conditions and Mitigations

• If affected artifacts are not executed, malicious code execution via startup hooks does not occur (the absence of collection-suppression markers does not prove safety).
• Immediately isolate affected hosts, preserve forensic evidence without launching contaminated Python/pip environments, and rebuild from clean environments or virtual machines.
• Immediately revoke and reissue all credentials and secrets that were reachable from the compromised environment.

7. What Happens Upon Success

• Theft of credentials and SSH private keys for cloud environments (AWS, GCP, Azure, etc.), AI providers, CI/CD environments, and developers.
• Remote execution of additional Python payloads via the background loader.
• Lateral movement into CI/CD environments, cloud infrastructure, and downstream supply chain services using the stolen credentials.

8. Observable Logs

Inference: The following are candidate checks for internal investigations. Availability depends on products, permissions, configurations, and retention periods, and should be distinguished from confirmed observations in source reports. A single event alone does not confirm attribution to this incident or successful compromise.

Email

• No specific email vectors have been publicly disclosed.

Proxy / SWG / DNS

• Check for HTTP POST traffic from compromised environments to www.litellm.dev/healthcheck, as well as communication history with GitHub-hosted loader configuration endpoints or instructed external servers (distinguish clearly from normal LiteLLM API requests).

Endpoint / EDR

• Check for the presence of cook.pth, cook.py, and sitecustomize.py, affected container image digests, Python process execution history, access to target collection files (SSH keys, cloud configs, browser data), independent loader processes, and /tmp/remote_code_loader.lock (do not launch Python in contaminated environments for investigation purposes).

Identity / IdP

• Investigate unusual usage histories for cloud IAM roles, AI provider API keys, GitHub/npm/PyPI tokens, and SSH keys that were accessible from the compromised environment.

SaaS / Cloud

• Review package registry retrieval logs, CI/CD runners and build caches, and host-related cloud audit logs (such as CloudTrail) to investigate API calls originating from unusual IP addresses or regions.

Network

• Track connections to data exfiltration destinations and subsequent traffic utilizing stolen credentials in chronological order (traffic attempts alone do not confirm completed data transmission).

9. Attack Success Determination

Confirmed in Public Information

The introduction of malicious artifacts into official distribution channels, along with the implementation of startup hooks and remote loaders, has been confirmed by LiteLLM official statements and multiple security researchers. However, this does not imply that execution or data theft succeeded in every organization that deployed the software.

Determination Criteria for Your Organization

• Initial Execution Confirmed: Identified process execution history or related files where startup hooks were loaded, in addition to the introduction of affected artifacts (mere download or pull does not constitute execution success).
• Credential Theft or Session Compromise Confirmed: Supported by the presence of the success marker file /tmp/.pc_once_72129118c59f5636c0bb or confirmed HTTP 200 completion logs to exfiltration destinations. The absence of markers or connection attempts alone does not confirm success.

10. Investigation Playbook

• Trigger: Initiate investigations based on the deployment of LiteLLM 1.107.0, affected container digests, detection of cook.pth / sitecustomize.py, or traffic destined for litellm.dev.
• Initial Checks: Verify package deployment history, container digests, execution times around 2026-10-21, outbound traffic, and IAM roles assigned to hosts.
• Endpoint and Server Investigation: Do not launch Python within affected environments; preserve and investigate site-packages, lock files, processes, and persistence settings offline (e.g., via mounted storage).
• Credential and Cloud Investigation: Check usage histories for AWS CloudTrail (such as GetCallerIdentity), AI provider keys, GitHub/npm/PyPI tokens, and SSH private keys.
• Follow-up Actions: Track external cloud API executions, repository tampering, deployment of additional payloads, internal reconnaissance, and data exfiltration.
• Containment: Immediately isolate affected hosts from the network, rebuild them, pin to verified artifacts, and revoke and reissue all secrets that were accessible.
• Assessment Categories: Clearly distinguish between contact, execution, authentication success, data acquisition, and subsequent compromise stages, without presuming unconfirmed success.

11. Defense and Detection Ideas

• Single Events: Detect the generation of cook.pth / sitecustomize.py, creation of /tmp/remote_code_loader.lock, and traffic destined for litellm.dev/healthcheck.
• Chronological Correlation: Correlate the flow of package retrieval -> Python process execution -> credential file access -> archive generation -> litellm.dev communication -> cloud API usage.
• Threat Hunting: Comprehensively search for affected artifacts across PyPI installation logs, container pull logs, SBOMs, image digests, and CI runner caches.
• Log Limitations: The absence of marker files does not prove the absence of compromise, as container terminations or temporary file deletions may have erased traces.
• Priority Mitigations: Prioritize pinning to artifacts confirmed safe, verifying digests, checking build provenance, enforcing least privilege on secrets, strictly limiting outbound traffic, and comprehensively reissuing all accessible secrets (avoid relying solely on official signatures for safety determinations).

12. Facts / Inference / Hypothesis

Facts

• LiteLLM announced on October 21, 2026, that its release pipeline was compromised, resulting in malware injected into all 7 wheel variants of PyPI litellm 1.107.0 and multiple Docker/GHCR tags.
• On May 27, 2026, an Agent Platform master key was committed to a public repository; although history was overwritten via force-push, the key was not revoked. Attackers used this key on October 10 to obtain an organization owner GitHub CLI OAuth token from the Agent Platform API.
• Using the owner token, they ran a temporary workflow to additionally exfiltrate two maintainer tokens and other secrets. The attackers used the owner token to bypass branch protection, triggered a staging workflow, approved the production gate with one maintainer token, and deleted run records with the other maintainer token. Finally, they used the owner token to force-push main and revert surface history.
• cook.pth and sitecustomize.py execute automatically upon Python startup, collecting and encrypting credentials, private keys, and browser data for cloud, AI provider, and CI/CD environments before transmitting them to litellm.dev.
• An independently operating loader periodically checks GitHub pointers and fetches/executes additional Python code from external servers.
• The seven PyPI wheels were affected between 11:39:51 and 13:23 UTC on October 21, and Docker Hub tags (v1.107.0, latest, main-latest, main-stable) between 11:46:56 and 14:20 UTC. Affected GHCR tags became unavailable by 13:51 UTC. The official GitHub v1.107.0 source tag contained no malicious files and is distinct from distribution artifacts originating from attacker-controlled repositories; Enterprise Private releases were unaffected.

Inference

• If executed on AI gateways or CI runners, compromises may cascade beyond AI provider keys to host IAM roles and downstream systems.

Hypothesis

No additional hypotheses. Unconfirmed items are listed under "Unknowns and Additional Investigations".

13. MITRE ATT&CK Mapping

14. Unknowns and Additional Investigations

• While the master key exposure in the public repository and GitHub token acquisition path have been established, the specific method by which attackers discovered the exposed key, the full scope of use for exfiltrated secrets, and potential downstream unauthorized usage remain unknown.
• The number of organizations that actually installed and executed the software during the distribution window, and the success scope of data exfiltration across environments.

15. Impact on SOCs and Organizations

Organizations deploying LiteLLM as an AI gateway, development environment, CI/CD pipeline, or Kubernetes environment should immediately check execution history for version 1.107.0 or subsequent tracking tags, promptly isolate and rebuild affected hosts, and reissue all accessible secrets from a clean environment.

16. Summary by Target Audience

• For SOCs: Correlate and monitor artifact digests, cook.pth / sitecustomize.py, /tmp/remote_code_loader.lock, traffic destined for litellm.dev, and external cloud credential usage.
• For Administrators: Isolate hosts without launching Python or pip in affected environments, pin to officially verified safe versions (temporary recommendation at announcement was 1.106.2), and rebuild. Revoke and reissue all accessible secrets from a clean environment. Verify latest versions and digests through official advisories.
• For Users: General developers and users who do not directly manage LiteLLM should follow instructions from infrastructure administrators to inspect devices and reset passwords.