LiteLLM Compromised in Supply Chain Attack Delivering Credential Stealer and Backdoor

Summary

On October 21, 2026, The Hacker News reported that LiteLLM 1.107.0 had been compromised in a software supply-chain attack distributing a credential stealer and a backdoor through PyPI wheels and Docker images. The package was reportedly quarantined on PyPI and the malicious container images removed. These findings come from the single supplied article; the underlying analyses it references were not separately supplied for corroboration.^[0]

According to statements attributed to LiteLLM security director Oliver Jensen, malicious actions involved three engineers' GitHub accounts and appeared to use stolen GitHub CLI OAuth tokens. One account triggered the project-releaser run and another approved it. The token-acquisition mechanism remained unresolved, and LiteLLM could not rule out further access to those accounts. It reported revoking involved tokens, restricting organization membership, and removing registry trust links to its GitHub organization.^[0]

The malicious wheels used cook.pth to execute code at Python startup, without requiring an explicit LiteLLM import. The collector targeted cloud and developer credentials, private keys, AI-tool authentication files, browser data, environment variables, and LiteLLM proxy configuration. A separate background daemon provided hourly dead-drop checks and execution of attacker-supplied Python. The article advised exposed users to replace credentials from a clean environment and pin version 1.106.2 by digest; it did not attribute this incident to a named actor.^[0]

Attack chain

1. 1. Release-account access: The attacker acted through three engineers' GitHub accounts, apparently using stolen GitHub CLI OAuth tokens. The supplied report does not establish how the tokens were obtained.^[0]
2. 2. Release-workflow execution and approval: One compromised account triggered the project-releaser workflow and another approved it, enabling publication of the malicious release through the project's release process.^[0]
3. 3. Compromised artifact distribution: LiteLLM 1.107.0 was distributed through malicious PyPI wheels and Docker images. Seven wheel builds were listed as affected. The source archive also contained a tampered pyproject.toml, although it did not contain the payload files.^[0]
4. 4. Python-startup execution: The cook.pth file contained the line import cook, launching the credential collector when the Python interpreter started rather than waiting for an explicit LiteLLM import.^[0]
5. 5. Credential collection and exfiltration: The collector harvested credentials and development data, including LiteLLM proxy secrets and model configuration. It packaged collected material into a GZIP-compressed TAR archive for an HTTP POST to litellm.dev at /healthcheck.^[0]
6. 6. Backdoor branch and remote tasking: A second payload forked a background daemon that checked a GitHub dead drop hourly. It read domain.txt from the location identified as letters9813; if a domain was returned, the malware could rerun the stealer and fetch and execute Python from that domain's /codepy endpoint. The GitHub location was reportedly returning 404 when the article was published.^[0]

Disclosure timeline

How it works

The reported access mechanism was misuse of release privileges through engineers' GitHub accounts, not a disclosed LiteLLM software flaw. The apparent use of stolen GitHub CLI OAuth tokens and separate accounts for workflow triggering and approval explains how the attacker operated within the release process, but the initial token-theft mechanism remained unknown.^[0]

The execution mechanism relied on Python startup processing of a path file. The supplied report identifies cook.pth and its single line, import cook, as the trigger for the credential collector. Consequently, assessing exposure only by whether an application explicitly imported LiteLLM would miss the reported execution condition.^[0]

The first payload, described as calling itself privcollect, combined broad credential harvesting with LiteLLM-specific collection. Its targets included cloud tokens, developer accounts, private keys, AI-tool credential JSON files, Chromium and Firefox data, environment variables, and the proxy's saved credentials and model configuration. The reported exfiltration format was a GZIP-compressed TAR archive sent by HTTP POST to /healthcheck on litellm.dev.^[0]

The second payload supported continuing remote execution through a forked daemon and hourly GitHub dead-drop checks. A domain obtained from domain.txt supplied a destination for renewed collection and retrieval of Python from /codepy. This was a described malware capability; the supplied article did not document commands executed on specific downstream victims.^[0]

Affected versions and patch status

Indicators of Compromise

Key takeaways

• Exposure assessment must account for Python-startup execution: an explicit LiteLLM import was not required for the reported collector to launch.^[0]
• Recovery extends beyond replacing the package. The payload targeted credentials across cloud, development, browser, AI-tooling, and LiteLLM proxy contexts, and the article explicitly recommended credential replacement from a clean environment.^[0]
• Artifact scope matters: the wheels carried the reported payloads, while the source archive was described as containing a tampered build configuration without payload files. Those findings should not be collapsed into identical execution claims.^[0]
• Attribution remains limited. The article's TeamPCP comparison concerns earlier LiteLLM compromises and a similar startup technique; it does not establish that TeamPCP conducted the 1.107.0 operation.^[0]

Defensive actions

• Identify LiteLLM 1.107.0 wheel and container deployments and replace the compromised release using the article's recommended 1.106.2 digest-pinned fallback.: The report identifies 1.107.0 wheels and Docker images as the malicious distribution channels and explicitly recommends pinning 1.106.2 by digest.^[0]
• Revoke and replace exposed credentials from a clean environment.: This is the article's explicit recovery recommendation. Prioritize the reported collection scope: cloud and developer credentials, private keys, AI-tool authentication files, browser-held authentication data, environment secrets, and LiteLLM proxy credentials.^[0]
• Assess Python-startup activity in affected environments, not only application logs showing LiteLLM imports. Inspect for cook.pth containing import cook.: The reported path-file mechanism launches the collector when Python starts, before LiteLLM is explicitly imported.^[0]
• Review outbound telemetry for litellm.dev, particularly HTTP POST requests to /healthcheck, and restrict access to that reported exfiltration host.: The collector was designed to send archived stolen data to that destination. The destination and request path provide incident-specific network hunting criteria.^[0]
• Search GitHub access telemetry for letters9813 and associated domain.txt retrieval, and investigate related /codepy requests.: The reported daemon used this dead-drop mechanism for hourly checks, renewed collection, and execution of remotely supplied Python. The reported 404 response does not establish whether earlier retrievals succeeded.^[0]
• For the affected release organization, maintain the reported containment of involved GitHub tokens, organization access, and registry trust while investigating token acquisition and residual account access.: LiteLLM reported revoking the tokens, retaining only one unaffected organization user temporarily, and removing registry trust links. It also stated that the token-acquisition mechanism was unresolved and further account access could not yet be ruled out.^[0]