> ## Content Index > Fetch the complete content index at: https://f4n6.co.uk/llms.txt > Use this file to discover other available public pages before exploring further. # LiteLLM supply chain attack delivers RAT and stealer via version 1.107.0 - URL: https://f4n6.co.uk/security-feed/litellm-supply-chain-attack-delivers-rat-and-stealer-via-version-1-107-0/ - Published: 2026-10-25T13:12:31.000Z - Updated: 2026-10-25T13:12:31.000Z - Author: Jeff Davies - Tags: #security-feed ## 1\. Executive summary On 21 October 2026 LiteLLM version 1.107.0 was published to PyPI and Docker Hub carrying a credential stealer and a remote access trojan, after attackers used stolen GitHub CLI OAuth tokens belonging to three LiteLLM developers to alter the release pipeline and point it at a lookalike repository, Berri-AI/litellm. The malicious package was live for roughly three hours and downloaded more than 49,000 times; the most recent clean release is 1.106.2\. Any EMEA financial services firm running LiteLLM as an LLM gateway, or with the package on developer workstations, CI/CD agents or containers, should treat every credential reachable from those environments as exposed, because the payload executes on Python interpreter startup whether or not the application imports LiteLLM. No CVE has been assigned and the item is not in CISA KEV; this is a supply chain compromise, not a patchable software flaw. The exposure is concentrated in cloud identities, model-provider API keys and source-control tokens that sit alongside LiteLLM in production and build environments. ## 2\. Regulatory framing | Article | Trigger (the fact in this item) | Practical impact | | ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | DORA Art. 28 | LiteLLM is an ICT third-party component whose compromised release entered client environments through PyPI and Docker Hub, and the intrusion originated in the provider's own release pipeline and an internet-exposed internal deployment. | Third-party risk assessment must cover the provider's build and release integrity, not just the running product. Review what the LiteLLM contract says about the provider's obligation to secure its pipeline and to notify of a compromise. | | DORA Art. 30 | The compromise was enabled by a leaked master key committed to a public GitHub repository and by release workflow changes made with stolen developer tokens, both of which are contractual security and audit concerns with the provider. | Check whether existing contracts give you audit rights over the provider's development and release controls, and whether notification timelines and cooperation duties cover a pipeline compromise of this kind. | | NIS2 Art. 21(2)(d) | The malicious artefact reached clients through the software supply chain (PyPI wheels and Docker images), and the payload harvests cloud, source-control and CI/CD credentials that are themselves supply chain access paths. | Supply chain security measures must extend to package and container provenance for AI tooling, and to the credential hygiene of build systems that pull third-party Python packages. | ## 3\. Technical analysis & attack chain The compromise was a release-pipeline takeover, not a vulnerability in LiteLLM's runtime code. Attackers obtained GitHub CLI OAuth tokens for three LiteLLM developer accounts and used them to disable branch protections, merge a change redirecting the releaser to a different source repository, and run a compromised GitHub workflow pointing at the lookalike repository Berri-AI/litellm (one hyphen from the legitimate BerriAI/litellm), then signed and published the poisoned artefacts. Confirmed steps: 1. A configuration file committed on 27 May 2026 to the public LiteLLM-Labs/lite-harness repository inadvertently contained the master key to an internal LiteLLM deployment exposed to the public internet. LiteLLM suspects the attacker reached that deployment through a recently patched vulnerability, but states it has not confirmed the initial access path. 2. The attacker lifted GitHub CLI OAuth tokens from the deployment's logs. LiteLLM found that Claude Code can, in specific circumstances, embed a user's GitHub CLI OAuth token in a response body, which is then written to LiteLLM logs where the attacker could retrieve it. 3. Using the stolen tokens across three developer accounts, the attacker disabled branch protections, redirected the release workflow to Berri-AI/litellm, obtained a production approval from a second account, and deleted the workflow records from a third, limiting the logs available to investigators. 4. At 04:00 PST (11:39 UTC) on 21 October the pipeline published 1.107.0\. PyPI carried it from 11:39 to 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. Socket counted seven builds covering macOS, Linux and Windows. 5. The payload dropped three files into the site-packages root: cook.pth, a path-extension file that causes cook.py to run every time Python is invoked; cook.py, the infostealer; and sitecustomize.py, the RAT, which Python also executes at interpreter startup. No import of LiteLLM is required, so developer workstations, CI runners, test systems and containers that merely started Python with the package installed are in scope. 6. The stealer runs 16 collection modules. It takes browser credentials and cookies from Chrome, Firefox, Edge and Safari; AWS credentials from \~/.aws/, environment variables and EC2/ECS instance metadata (IMDS); 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 and shell history; and authentication files for Codex, Claude, Gemini and Cursor. A separate module reads credential and model-configuration records from the LiteLLM proxy database. 7. Collected data is encrypted with AES-256-CBC, the key wrapped with an RSA-4096 public key, and sent by HTTP POST to http://www\[.\]litellm\[.\]dev/healthcheck. 8. The RAT spawns a background daemon that polls the attacker's infrastructure hourly for Python to execute, and checks a GitHub dead drop every hour, running whatever Python the attacker serves. Wiz observed the attackers querying Amazon Bedrock models with stolen AWS credentials roughly 4.5 hours after exfiltration, which points to LLMjacking (unauthorised use of the victim's model quota). LiteLLM states enterprise customers pulling from its private registry were not affected. The payload was likely built with AI assistance, per the reporting; that is a single-source characterisation and does not change the response. Confidence caveats. The initial access vector into LiteLLM's internal deployment is unconfirmed by LiteLLM and not independently determined by Microsoft. The token-leak-via-Claude-Code mechanism is LiteLLM's own hypothesis. The 49,000 download figure and the three-hour window come from the primary reporting and are consistent across sources; the 23 million weekly download figure is Socket's. No actor is named in any source and no MITRE ATT&CK profile is available for this item, so attribution is unconfirmed. The March 2026 LiteLLM compromise and the 2,500-organization exposure figure reported by CloudSEK and Hudson Rock concern a separate earlier incident and should not be conflated with this one. ## 4\. Mitigation & containment P1 within 24 hours. - Identify every environment that installed LiteLLM 1.107.0 or pulled the Docker tags v1.107.0, latest, main-latest or main-stable between 11:39 and 14:20 UTC on 21 October. Do not start Python or pip inside a suspect environment to test for the package; doing so executes the payload. Inspect the filesystem from outside the interpreter. - On suspect hosts check for /tmp/.pc\_once\_\* (the exfiltration has already fired if present) and /tmp/remote\_code\_loader.lock (the C2 daemon ran or is still running if present), and for cook.pth, cook.py and sitecustomize.py in the site-packages root. - Treat every credential reachable from an affected environment as compromised and rotate: AWS, GCP and Azure credentials and tokens, Kubernetes and Docker credentials, GitHub and other source-control tokens, SSH private keys, GPG keys, model-provider API keys (OpenAI, Anthropic, Cohere and others), and any LiteLLM master key or database credentials. Revoke sessions, not just passwords. - Block outbound access to litellm\[.\]dev and www\[.\]litellm\[.\]dev at egress, and hunt proxy and DNS logs for POSTs to /healthcheck. - Pin LiteLLM to 1.106.2 or later clean releases, and pin by digest for container images rather than by tag. P2 within 72 hours. - Review cloud billing and model-provider usage for anomalous Bedrock, OpenAI or Anthropic consumption consistent with LLMjacking, and check for new IAM principals, access keys or role assumptions created after 21 October. - Audit GitHub organisation settings for the changes the attacker made: disabled branch protections, altered release workflows, new or modified workflow files, and deleted workflow runs around 21 October. Re-enable protections and require review on release workflows. - Search LiteLLM and application logs for GitHub CLI OAuth tokens or other secrets written into response bodies, and purge or restrict logging of response bodies that may contain credentials. P3 within 7 days. - Remove secrets from build logs and CI output, shorten token lifetimes, and move release signing to a controlled identity that does not depend on individual developer OAuth tokens. - Add provenance verification for Python packages and container images used in AI tooling, and restrict which registries and repositories build agents may pull from. ## 5\. Indicators of compromise | type | value | confidence | source | | ---------- | ---------------------------------------------------------------- | ---------- | ------------------------------- | | domain | litellm\[.\]dev | high | The Register, SecurityWeek | | url | hxxp://www\[.\]litellm\[.\]dev/healthcheck | high | The Register | | filepath | cook.pth | high | The Register, Microsoft | | filepath | cook.py | high | The Register, Microsoft | | filepath | sitecustomize.py | high | The Register, Microsoft | | filepath | /tmp/.pc\_once\_\* | medium | The Register (Aikido) | | filepath | /tmp/remote\_code\_loader.lock | medium | The Register (Aikido) | | package | litellm 1.107.0 (PyPI) | high | SecurityWeek, Help Net Security | | image | litellm/litellm:1.107.0 | high | The Register | | image | litellm/litellm:latest, main-latest, main-stable (21 Oct window) | high | Help Net Security, The Register | | repository | github.com/Berri-AI/litellm (lookalike) | high | The Register, Microsoft | The /tmp paths are behavioural artefacts reported by Aikido and relayed by The Register; treat as single-sourced and verify before building enforcement around them. ```iocs domain litellm[.]dev url hxxp://www[.]litellm[.]dev/healthcheck filepath cook.pth filepath cook.py filepath sitecustomize.py filepath /tmp/.pc_once_* filepath /tmp/remote_code_loader.lock package litellm 1.107.0 image litellm/litellm:1.107.0 repository github.com/Berri-AI/litellm ``` No file hashes are available in the source material. Behavioural indicators: | behaviour | where to observe | confidence | | ----------------------------------------------------------------------------------------- | ---------------------------------------------------- | --------------------- | | Python interpreter startup spawns a background process that polls an external host hourly | EDR process telemetry, outbound network logs | high | | HTTP POST to /healthcheck on litellm\[.\]dev carrying encrypted body | proxy and firewall logs | high | | Hourly retrieval of Python from a GitHub dead drop | GitHub audit logs, egress to github.com from servers | medium (StepSecurity) | | Reads of \~/.aws/, GCP ADC, Azure CLI cache, SSH and GPG key material by a Python process | EDR file-access telemetry | high | | Reads of LiteLLM proxy database credential and model-config records | database audit logs | medium (Microsoft) | ## 6\. Detection ```yara rule Python_StartupHook_LiteLLM_Stealer { meta: author = "Adverse Trace" date = "2026-10-25" reference = "https://www.theregister.com/security/2026/10/21/litellm-supply-chain-attack-hoovers-up-passwords-and-secrets/5304548" description = "Detects LiteLLM 1.107.0 startup-hook stealer and RAT artefacts (cook.pth, cook.py, sitecustomize.py) by embedded exfiltration endpoint and lock paths" strings: $u1 = "litellm.dev/healthcheck" ascii wide $u2 = "www.litellm.dev" ascii wide $p1 = "/tmp/.pc_once_" ascii $p2 = "/tmp/remote_code_loader.lock" ascii $f1 = "cook.pth" ascii $f2 = "sitecustomize.py" ascii condition: uint32(0) != 0x04034b50 and 2 of ($u*) or 2 of ($p*) or ($f1 and $f2) } ``` The rule targets the exfiltration endpoint and the lock-file paths, which are the distinctive artefacts of this payload. It will not match the legitimate LiteLLM package, which does not reference litellm.dev or these /tmp paths. ```yaml title: LiteLLM 1.107.0 Stealer Exfiltration to litellm.dev id: 8f2c1a4e-litellm-2026 status: experimental description: Detects outbound HTTP POST to the LiteLLM 1.107.0 stealer endpoint /healthcheck on litellm.dev author: Adverse Trace date: 2026/10/25 references: - https://www.theregister.com/security/2026/10/21/litellm-supply-chain-attack-hoovers-up-passwords-and-secrets/5304548 logsource: category: proxy detection: selection: cs-method: 'POST' r-dns|endswith: - 'litellm.dev' cs-uri|contains: '/healthcheck' condition: selection falsepositives: - None expected; litellm.dev is not a legitimate LiteLLM service endpoint level: critical ``` ```yaml title: Python Startup Hook Files Written to site-packages id: 3b7d9c2f-litellm-hook-2026 status: experimental description: Detects creation of cook.pth, cook.py or sitecustomize.py in a Python site-packages directory, the persistence mechanism of LiteLLM 1.107.0 author: Adverse Trace date: 2026/10/25 references: - https://www.microsoft.com/en-us/security/blog/2026/10/23/inside-the-litellm-1-107-0-supply-chain-compromise-credential-theft-through-python-startup-hooks/ logsource: category: file_event detection: selection: TargetFilename|endswith: - '\site-packages\cook.pth' - '\site-packages\cook.py' - '\site-packages\sitecustomize.py' - '/site-packages/cook.pth' - '/site-packages/cook.py' - '/site-packages/sitecustomize.py' condition: selection falsepositives: - Legitimate sitecustomize.py deployed by an organisation's own Python build; baseline before alerting level: high ``` ## 7\. Sources - SecurityWeek, "LiteLLM Compromised in Fresh Supply Chain Attack", https://www.securityweek.com/litellm-compromised-in-fresh-supply-chain-attack/, 2026-10-23. - 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, "LiteLLM Compromised in Supply Chain Attack Delivering Credential Stealer and Backdoor", https://thehackernews.com/2026/10/litellm-compromised-in-supply-chain.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. - 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. - Microsoft Threat Intelligence, "Inside the LiteLLM 1.107.0 supply chain compromise: Credential theft through Python startup hooks", https://www.microsoft.com/en-us/security/blog/2026/10/23/inside-the-litellm-1-107-0-supply-chain-compromise-credential-theft-through-python-startup-hooks/, 2026-10-23. ## 8\. Adverse Trace position Adverse Trace assesses this as a high-impact supply chain compromise with no CVE and no CISA KEV entry, so severity is driven by credential exposure rather than by a patchable flaw: any environment that ran 1.107.0 should assume its cloud, source-control and model-provider credentials are in attacker hands, and the LLMjacking observation means the attacker may already be consuming model quota under the victim's identity. No actor is named and no MITRE ATT&CK profile exists for this item, so attribution is unconfirmed and we do not attribute. The initial access path into LiteLLM's deployment is unconfirmed by the vendor and the /tmp lock-file indicators are single-sourced; verify before enforcing on them. We will monitor LiteLLM's investigation for the confirmed initial access vector and any additional indicators, and will issue an update if the scope of affected environments widens. Clients running LiteLLM should begin the P1 credential rotation and filesystem sweep now rather than waiting for a vendor post-mortem. --- [Read the original source →](https://www.securityweek.com/litellm-compromised-in-fresh-supply-chain-attack/?ref=f4n6.co.uk) *Published via PulseTrace — Adverse Trace threat intelligence.*