Anoymask

Posted on Oct 23

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

Anoymask · 2026-10-23T17:45:15Z

1. Basic Information Article Name : Contained: Oct 21, 2026 LiteLLM release v1.107.0 Compromised Publisher : LiteLLM Publication Date : 2026-10-21 Original Source : Contained: Oct 21, 2026 LiteLLM release v1.107.0 Compromised Related Sources : BleepingComputer: LiteLLM release pipeline hacked , Socket: LiteLLM PyPI Package and Docker Images Compromised , Endor Labs: LiteLLM 1.107.0 Compromised Related Malware and Threat Groups : cook.pth, cook.py, sitecustomize.py Related CVE : None Related Products : LiteLLM, PyPI, Docker Hub, GitHub Container Registry Severity : Critical Basis of Severity : Credentials for cloud environments, CI/CD, AI providers, browsers, and SSH are stolen from officially signed and distributed artifacts, and additional code can be executed from external sources. 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 injected files are loaded at startup, executing Python or pip commands triggers the malicious code even without explicitly importing LiteLLM. Note that due to suppression environment variables and success markers, data theft may not occur in every execution. 3. Attack Flow Attack and Exploitation Chain Reconstructed from Public Information LiteLLM confirmed that the attacker used three sets of developer GitHub CLI credentials, including an organization owner's token. The company suspects that the attacker obtained tokens from internal LiteLLM logs; the initial access path remains under investigation. Attackers abused repository owner privileges to disable branch protection rules and modified the release workflow source reference to a spoofed repository (Berri-AI/litellm). The modified official release workflow signed and published poisoned wheels to PyPI through Trusted Publishing and also published poisoned container images. Python startup hooks (.pth / sitecustomize) automatically executed the malicious script in deployed environments to collect and transmit credentials, while a background loader fetched and executed additional code from external sources. The table summarizes the public information above. Defender signals are suggestions for investigation in your own environment (Inference). Undisclosed implementation details and follow-on behavior are left unspecified. Attack Stage Attacker Actions and Techniques Tools and Communications Defender Signals (Prerequisites and Artifacts) 1. Credential Theft Used three sets of developer GitHub CLI credentials. Internal environment intrusion and log-based acquisition are provider investigation hypotheses GitHub CLI OAuth tokens (acquisition path under investigation) Abnormal GitHub API access, modification of administrator settings 2. Pipeline Tampering Disabled branch protection and redirected the release workflow source reference to the spoofed repository GitHub Actions, repository settings changes Branch protection removal logs, workflow changes referencing external repositories 3. Malicious Package Distribution Signed and published via the modified official workflow; wheels used PyPI's Trusted Publishing path PyPI, Docker Hub, GHCR Short-lived compromised release (v1.107.0), signed malicious wheels and affected image digests 4. Execution and Information Theft Collected and transmitted environment variables and secrets via cook.pth / sitecustomize.py during Python startup HTTP POST ( www.litellm.dev/healthcheck ), external loader communications File access during process startup, /tmp/remote_code_loader.lock , marker creation 4. Attacker Location and Execution Venue A remote attacker possessing stolen GitHub credentials who is able to operate the LiteLLM release repository and workflow. 5. Visibility for Victims and Administrators Victims Installed as an official distribution via standard pip install or docker pull , with the malware running in the background upon Python execution. Administrators and SOCs Observable as installed package versions, container image digests, Python startup-related files (.pth), suspicious external communications, and unusual cloud activity recorded in audit logs. 6. Success and Failure Conditions Success Conditions Deployment of a malicious wheel or affected container image, and execution in an environment where its Python startup hooks are loaded (clearly distinguishing between mere download/pull and actual execution). Even after public withdrawal, local caches, mirrors, and saved images may retain affected artifacts. Residual cached copies are not a prerequisite for exploitation; verify the actually executed digest and installed files rather than just tag names. Successful credential theft requires that target secrets are readable from the executing process and that network reachability to the destination exists (distinguishing the success of hook startup, information gathering, and external transmission). Failure Conditions and Mitigations If affected artifacts have not been executed, malicious code execution via startup hooks will not occur (the absence of a suppression marker does not prove safety). Immediately isolate affected hosts, preserve evidence without launching the contaminated Python/pip, and rebuild from a clean environment or virtual machine. Immediately revoke and reissue all reachable credentials and secrets from a secure, clean environment. 7. What Happens Upon Success Theft of various credentials and SSH private keys for cloud environments (AWS, GCP, Azure, etc.), AI providers, CI/CD environments, and developers. Remote execution of additional Python code by the background loader. Further compromise of CI/CD environments, cloud infrastructure, and downstream services using the stolen credentials. 8. Observable Logs Inference: The following are candidates for internal investigation. Availability depends on products, permissions, configurations, and retention periods, and must be distinguished from observation records in source reports. A single event alone does not confirm attribution or successful compromise in this incident. Email No email vectors specific to this incident have been publicly disclosed. Proxy / SWG / DNS Check for HTTP POST communications from the compromised environment to www.litellm.dev/healthcheck , as well as requests to the GitHub-hosted loader configuration or pointer and connections to the external server it identifies (distinct 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 targeted files (SSH keys, cloud configurations, 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 of cloud IAM roles, AI provider API keys, GitHub/npm/PyPI tokens, and SSH keys that were accessible from the compromised environment. SaaS / Cloud Check package registry retrieval logs, CI/CD runners and build caches, and host-related cloud audit logs (such as CloudTrail) to investigate API calls from unusual IPs or regions. Network Track connections to data exfiltration destinations and subsequent communications using stolen credentials in chronological order (communication attempts alone do not equate to completed data transmission). 9. Attack Success Determination Confirmed in Public Information The inclusion of malicious artifacts in official distribution channels, as well as the implementation of startup hooks and remote loaders, has been confirmed by LiteLLM officials and multiple security researchers. However, this does not imply that execution or data theft succeeded in every deployed organization. Criteria for Internal Determination Initial Execution Confirmed : In addition to deploying affected artifacts, process execution history or related files where startup hooks were loaded are identified (mere download or pull does not constitute successful execution). Information Theft or Session Compromise Confirmed : Supported by the existence of the success marker file /tmp/.pc_once_72129118c59f5636c0bb or HTTP 200 completion logs to the transmission destination. Neither a missing marker nor a communication attempt alone establishes whether exfiltration succeeded. 10. Investigation Playbook Trigger : Initiation based on LiteLLM 1.107.0 deployment, affected container digests, detection of cook.pth / sitecustomize.py , or communications directed to litellm.dev . Initial Review : Verify package deployment history, container digests, execution times on 2026-10-21, outbound communications, and IAM roles assigned to the host. 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 mount inspection). Identity and Cloud Investigation : Check usage history for AWS CloudTrail ( GetCallerIdentity , etc.), AI provider keys, GitHub/npm/PyPI tokens, and SSH private keys. Subsequent 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 them to verified artifacts, and revoke and reissue all accessible secrets. Determination Categories : Clearly distinguish between contact, execution, authentication success, data acquisition, and subsequent compromise phases, without assuming unconfirmed successes. 11. Defense and Detection Ideas Single Events : Detect the generation of cook.pth / sitecustomize.py , creation of /tmp/remote_code_loader.lock , and communications to litellm.dev/healthcheck . Chronological Correlation : Correlate package acquisition -> Python process startup -> credential file access -> archive generation -> litellm.dev communication -> cloud API usage flows. Threat Hunting : Comprehensively search for affected artifacts in PyPI installation logs, container pull logs, SBOMs, image digests, and CI runner caches. Log Limitations : The absence of marker files does not prove a lack of compromise; traces may have been lost due to container termination or temporary directory deletion. Priority Mitigations : Prioritize pinning to verified safe artifacts and digest verification, provenance verification including build sources, least privilege for secrets, strict outbound traffic restrictions, and full reissuance of reachable secrets (avoid relying solely on official signatures for safety judgments). 12. Facts / Inference / Hypothesis Facts LiteLLM announced on October 21, 2026, that its release pipeline was compromised, introducing malware into all 7 wheel variants of litellm 1.107.0 on PyPI and multiple Docker/GHCR tags. Attackers used three sets of developer GitHub CLI credentials, disabled branch protection with owner privileges, and specified the spoofed repository Berri-AI/litellm in the release workflow. cook.pth and sitecustomize.py execute automatically upon Python startup to collect, encrypt, and send credentials, private keys, and browser data for cloud, AI provider, and CI/CD environments to litellm.dev . An independently operating loader periodically checks pointers on GitHub and fetches/executes additional Python code from external servers. The 7 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 did not contain malicious files, distinguishing it from attacker-controlled repository distribution artifacts, and private enterprise releases were unaffected. Inference When 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. Unverified items are listed under "Open Questions and Further Investigation". 13. MITRE ATT&CK Mapping ID Technique Confidence Basis T1195.002 Compromise Software Supply Chain high Confirmed that malicious wheels and container images were distributed through official release and distribution channels. T1546 Event Triggered Execution medium Automatic execution via .pth and sitecustomize upon Python startup (distinguished from Unix shell configuration tampering T1546.004, choosing the parent technique). T1555 Credentials from Password Stores high Functions to extract browser saved passwords, cookies, and other credentials were confirmed in the analyzed collection scripts. Successful collection in each deployed environment requires separate verification. T1105 Ingress Tool Transfer high Implementation where the background loader downloads and executes additional Python code from external sources was confirmed. 14. Open Questions and Further Investigation Initial intrusion vector into the internal LiteLLM environment and the root cause of OAuth token leakage. Number of organizations that actually installed and executed the software during the distribution period, and the successful scope of data exfiltration in each environment. 15. Impact on SOCs and Organizations Organizations operating LiteLLM in AI gateways, development environments, CI/CD pipelines, Kubernetes environments, or similar deployments should immediately check execution histories for version 1.107.0 or floating 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 , communications to litellm.dev , and external usage of cloud credentials. For Administrators : Isolate hosts without launching Python or pip in affected environments, rebuild by pinning to versions officially confirmed as safe (provisional recommendation at the time of notice is 1.106.2). Revoke and reissue all accessible secrets from a clean environment. Verify adopted versions and digests against the latest official guidance. For Users : General developers and users who do not directly manage LiteLLM should follow instructions from infrastructure administrators to inspect devices and reset passwords.

#security #threatintel

1. Basic Information

Article Name: Contained: Oct 21, 2026 LiteLLM release v1.107.0 Compromised
Publisher: LiteLLM
Publication Date: 2026-10-21
Original Source: Contained: Oct 21, 2026 LiteLLM release v1.107.0 Compromised
Related Sources: BleepingComputer: LiteLLM release pipeline hacked, Socket: LiteLLM PyPI Package and Docker Images Compromised, Endor Labs: LiteLLM 1.107.0 Compromised
Related Malware and Threat Groups: cook.pth, cook.py, sitecustomize.py
Related CVE: None
Related Products: LiteLLM, PyPI, Docker Hub, GitHub Container Registry
Severity: Critical
Basis of Severity: Credentials for cloud environments, CI/CD, AI providers, browsers, and SSH are stolen from officially signed and distributed artifacts, and additional code can be executed from external sources. 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 injected files are loaded at startup, executing Python or pip commands triggers the malicious code even without explicitly importing LiteLLM. Note that due to suppression environment variables and success markers, data theft may not occur in every execution.

3. Attack Flow

Attack and Exploitation Chain Reconstructed from Public Information

LiteLLM confirmed that the attacker used three sets of developer GitHub CLI credentials, including an organization owner's token. The company suspects that the attacker obtained tokens from internal LiteLLM logs; the initial access path remains under investigation.
Attackers abused repository owner privileges to disable branch protection rules and modified the release workflow source reference to a spoofed repository (Berri-AI/litellm).
The modified official release workflow signed and published poisoned wheels to PyPI through Trusted Publishing and also published poisoned container images.
Python startup hooks (.pth / sitecustomize) automatically executed the malicious script in deployed environments to collect and transmit credentials, while a background loader fetched and executed additional code from external sources.

The table summarizes the public information above. Defender signals are suggestions for investigation in your own environment (Inference). Undisclosed implementation details and follow-on behavior are left unspecified.

Attack Stage	Attacker Actions and Techniques	Tools and Communications	Defender Signals (Prerequisites and Artifacts)
1. Credential Theft	Used three sets of developer GitHub CLI credentials. Internal environment intrusion and log-based acquisition are provider investigation hypotheses	GitHub CLI OAuth tokens (acquisition path under investigation)	Abnormal GitHub API access, modification of administrator settings
2. Pipeline Tampering	Disabled branch protection and redirected the release workflow source reference to the spoofed repository	GitHub Actions, repository settings changes	Branch protection removal logs, workflow changes referencing external repositories
3. Malicious Package Distribution	Signed and published via the modified official workflow; wheels used PyPI's Trusted Publishing path	PyPI, Docker Hub, GHCR	Short-lived compromised release (v1.107.0), signed malicious wheels and affected image digests
4. Execution and Information Theft	Collected and transmitted environment variables and secrets via `cook.pth` / `sitecustomize.py` during Python startup	HTTP POST (`www.litellm.dev/healthcheck`), external loader communications	File access during process startup, `/tmp/remote_code_loader.lock`, marker creation

4. Attacker Location and Execution Venue

A remote attacker possessing stolen GitHub credentials who is able to operate the LiteLLM release repository and workflow.

5. Visibility for Victims and Administrators

Victims

Installed as an official distribution via standard pip install or docker pull, with the malware running in the background upon Python execution.

Administrators and SOCs

Observable as installed package versions, container image digests, Python startup-related files (.pth), suspicious external communications, and unusual cloud activity recorded in audit logs.

6. Success and Failure Conditions

Success Conditions

Deployment of a malicious wheel or affected container image, and execution in an environment where its Python startup hooks are loaded (clearly distinguishing between mere download/pull and actual execution).
Even after public withdrawal, local caches, mirrors, and saved images may retain affected artifacts. Residual cached copies are not a prerequisite for exploitation; verify the actually executed digest and installed files rather than just tag names.
Successful credential theft requires that target secrets are readable from the executing process and that network reachability to the destination exists (distinguishing the success of hook startup, information gathering, and external transmission).

Failure Conditions and Mitigations

If affected artifacts have not been executed, malicious code execution via startup hooks will not occur (the absence of a suppression marker does not prove safety).
Immediately isolate affected hosts, preserve evidence without launching the contaminated Python/pip, and rebuild from a clean environment or virtual machine.
Immediately revoke and reissue all reachable credentials and secrets from a secure, clean environment.

7. What Happens Upon Success

Theft of various credentials and SSH private keys for cloud environments (AWS, GCP, Azure, etc.), AI providers, CI/CD environments, and developers.
Remote execution of additional Python code by the background loader.
Further compromise of CI/CD environments, cloud infrastructure, and downstream services using the stolen credentials.

8. Observable Logs

Inference: The following are candidates for internal investigation. Availability depends on products, permissions, configurations, and retention periods, and must be distinguished from observation records in source reports. A single event alone does not confirm attribution or successful compromise in this incident.

Email

No email vectors specific to this incident have been publicly disclosed.

Proxy / SWG / DNS

Check for HTTP POST communications from the compromised environment to www.litellm.dev/healthcheck, as well as requests to the GitHub-hosted loader configuration or pointer and connections to the external server it identifies (distinct 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 targeted files (SSH keys, cloud configurations, 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 of cloud IAM roles, AI provider API keys, GitHub/npm/PyPI tokens, and SSH keys that were accessible from the compromised environment.

SaaS / Cloud

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

Network

Track connections to data exfiltration destinations and subsequent communications using stolen credentials in chronological order (communication attempts alone do not equate to completed data transmission).

9. Attack Success Determination

Confirmed in Public Information

The inclusion of malicious artifacts in official distribution channels, as well as the implementation of startup hooks and remote loaders, has been confirmed by LiteLLM officials and multiple security researchers. However, this does not imply that execution or data theft succeeded in every deployed organization.

Criteria for Internal Determination

Initial Execution Confirmed: In addition to deploying affected artifacts, process execution history or related files where startup hooks were loaded are identified (mere download or pull does not constitute successful execution).
Information Theft or Session Compromise Confirmed: Supported by the existence of the success marker file /tmp/.pc_once_72129118c59f5636c0bb or HTTP 200 completion logs to the transmission destination. Neither a missing marker nor a communication attempt alone establishes whether exfiltration succeeded.

10. Investigation Playbook

Trigger: Initiation based on LiteLLM 1.107.0 deployment, affected container digests, detection of cook.pth / sitecustomize.py, or communications directed to litellm.dev.
Initial Review: Verify package deployment history, container digests, execution times on 2026-10-21, outbound communications, and IAM roles assigned to the host.
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 mount inspection).
Identity and Cloud Investigation: Check usage history for AWS CloudTrail (GetCallerIdentity, etc.), AI provider keys, GitHub/npm/PyPI tokens, and SSH private keys.
Subsequent 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 them to verified artifacts, and revoke and reissue all accessible secrets.
Determination Categories: Clearly distinguish between contact, execution, authentication success, data acquisition, and subsequent compromise phases, without assuming unconfirmed successes.

11. Defense and Detection Ideas

Single Events: Detect the generation of cook.pth / sitecustomize.py, creation of /tmp/remote_code_loader.lock, and communications to litellm.dev/healthcheck.
Chronological Correlation: Correlate package acquisition -> Python process startup -> credential file access -> archive generation -> litellm.dev communication -> cloud API usage flows.
Threat Hunting: Comprehensively search for affected artifacts in PyPI installation logs, container pull logs, SBOMs, image digests, and CI runner caches.
Log Limitations: The absence of marker files does not prove a lack of compromise; traces may have been lost due to container termination or temporary directory deletion.
Priority Mitigations: Prioritize pinning to verified safe artifacts and digest verification, provenance verification including build sources, least privilege for secrets, strict outbound traffic restrictions, and full reissuance of reachable secrets (avoid relying solely on official signatures for safety judgments).

12. Facts / Inference / Hypothesis

Facts

LiteLLM announced on October 21, 2026, that its release pipeline was compromised, introducing malware into all 7 wheel variants of litellm 1.107.0 on PyPI and multiple Docker/GHCR tags.
Attackers used three sets of developer GitHub CLI credentials, disabled branch protection with owner privileges, and specified the spoofed repository Berri-AI/litellm in the release workflow.
cook.pth and sitecustomize.py execute automatically upon Python startup to collect, encrypt, and send credentials, private keys, and browser data for cloud, AI provider, and CI/CD environments to litellm.dev.
An independently operating loader periodically checks pointers on GitHub and fetches/executes additional Python code from external servers.
The 7 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 did not contain malicious files, distinguishing it from attacker-controlled repository distribution artifacts, and private enterprise releases were unaffected.

Inference

When 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. Unverified items are listed under "Open Questions and Further Investigation".

13. MITRE ATT&CK Mapping

ID	Technique	Confidence	Basis
T1195.002	Compromise Software Supply Chain	high	Confirmed that malicious wheels and container images were distributed through official release and distribution channels.
T1546	Event Triggered Execution	medium	Automatic execution via `.pth` and `sitecustomize` upon Python startup (distinguished from Unix shell configuration tampering T1546.004, choosing the parent technique).
T1555	Credentials from Password Stores	high	Functions to extract browser saved passwords, cookies, and other credentials were confirmed in the analyzed collection scripts. Successful collection in each deployed environment requires separate verification.
T1105	Ingress Tool Transfer	high	Implementation where the background loader downloads and executes additional Python code from external sources was confirmed.

14. Open Questions and Further Investigation

Initial intrusion vector into the internal LiteLLM environment and the root cause of OAuth token leakage.
Number of organizations that actually installed and executed the software during the distribution period, and the successful scope of data exfiltration in each environment.

15. Impact on SOCs and Organizations

Organizations operating LiteLLM in AI gateways, development environments, CI/CD pipelines, Kubernetes environments, or similar deployments should immediately check execution histories for version 1.107.0 or floating 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, communications to litellm.dev, and external usage of cloud credentials.
For Administrators: Isolate hosts without launching Python or pip in affected environments, rebuild by pinning to versions officially confirmed as safe (provisional recommendation at the time of notice is 1.106.2). Revoke and reissue all accessible secrets from a clean environment. Verify adopted versions and digests against the latest official guidance.
For Users: General developers and users who do not directly manage LiteLLM should follow instructions from infrastructure administrators to inspect devices and reset passwords.

Top comments (2)

cryptostrapon • Oct 23

Worth stressing for readers: a .pth file runs on every Python start, not only at install, so installing with scripts disabled does not help here. Since the release was signed through the real pipeline, hash pinning would not have caught it either. What would have: a release cooldown in CI (minimumReleaseAge in Renovate, exclude-newer in uv), so a version only gets pulled after it has been public for a few days.

Gautam K • Oct 23 • Edited

The step that worries me most is number 2: one owner token was enough to switch off branch protection and repoint the release workflow, and nothing asked a second question at that moment. Changing branch protection is a single API call. In an approval broker I'm building, a PUT or DELETE on a branch protection rule waits for a person to approve it with a passkey, so a valid token alone can't do it.

That only helps if the raw token never sits where logs can catch it, which is where LiteLLM suspects these came from. Did LiteLLM say whether the owner token was a long lived CLI token or something scoped and short lived?