LiteLLM Supply Chain Attack Exposes Government AI Workload Risk

On October 21, 2026, attackers compromised the release workflow of LiteLLM, a widely adopted Python library that unifies API calls across multiple large language model providers and supports self-hosted proxy deployments, and distributed a malicious build numbered 1.107.0 through official PyPI wheels and Docker container registries. According to reporting from Upwind, Mezha.net, and the HoneyMex Lab, the compromised release bundled both a credential stealer and a remote-access trojan (RAT), giving adversaries persistent access to any environment that installed the package. The incident carries an estimated CVSS score of 9.8 (Critical) and maps to CWE-506 (Embedded Malicious Code) and CWE-434 (Unrestricted Upload of File with Dangerous Type). For government contractors, the exposure is direct and immediate: LiteLLM sits at the center of AI architectures that routinely handle sensitive API keys, cloud provider tokens, developer credentials, and model configurations, making its compromise a critical risk vector for organizational confidentiality.

The intrusion mechanism was methodical rather than opportunistic. Threat actors leveraged stolen GitHub CLI OAuth tokens belonging to three project engineers. One compromised account was used to trigger the automated project-releaser build run, while a second was used to approve it, allowing the malicious artifact to pass through normal release governance and land on official distribution channels. Persistence was achieved through a path configuration file named cook.pth containing a single-line instruction, import cook, which forces the Python interpreter to automatically load and execute the credential collector payload known as privcollect during session initialization — meaning the malware runs even before the LiteLLM library is explicitly imported, inside Python environments, container images, and CI runners alike.

The payload harvests cloud tokens, developer accounts, private keys, AI tooling credential JSON files, environment variables, and browser data associated with Chromium and Firefox, and it also extracts saved credentials and model configurations from LiteLLM deployments. Collected data is packaged into a GZIP-compressed TAR archive and exfiltrated via an HTTP POST request to litellm[.]dev/healthcheck, while a second payload forks a background control mechanism to maintain persistence. Security researchers from SafeDep, Socket, StepSecurity, and Upwind surfaced the discovery. Ilyas Makari, a malware hunter at Aikido Security, offered concrete forensic guidance: "Check for /tmp/.pc_once_* (the exfil has already fired if this file exists) and /tmp/remote_code_loader.lock (the C2 daemon ran or is still running if this file exists)." The signals identify version 1.106.2 as the prior safe release and do not report confirmed compromises of government systems — a critical distinction that leaves contractors in the detection and remediation window rather than confirmed incident response.

Procurement and security teams should treat this as a supply-chain governance problem, not just a patching exercise. Any contractor that installed or ran version 1.107.0 should halt deployment immediately, inventory affected systems and CI runners, and rebuild clean environments from known-good artifacts. Credentials and secrets accessible to those environments — cloud tokens, API keys, private keys, and AI tooling configuration files — should be treated as potentially compromised and rotated from a clean environment after exposure is investigated. More broadly, the incident underscores that software composition analysis, artifact signing, provenance attestation, and package and image integrity controls must be written into AI and cloud workload requirements, subcontract flow-downs, and vendor risk assessments. Because LiteLLM's compromise reached official channels via trusted developer credentials, traditional perimeter controls would not have stopped it. Government buyers evaluating AI tooling should expect vendors to demonstrate reproducible builds, protected release pipelines, and dependency monitoring that extends beyond the Python ecosystem into container registries and CI/CD infrastructure — the same attack surface that federal continuous monitoring and software supply-chain executive requirements are designed to address, though reporting did not tie this incident to any specific federal mandate.

• Attackers distributed compromised LiteLLM version 1.107.0 via PyPI and Docker registries on October 21, 2026, carrying a credential stealer and remote-access trojan.
• Estimated severity is CVSS 9.8 (Critical), categorized as CWE-506 and CWE-434, reflecting remote code execution and mass credential exfiltration risk.
• Compromise stemmed from stolen GitHub CLI OAuth tokens tied to three project engineers; one account triggered the release build and a second approved it.
• Malicious persistence used cook.pth with import cook, executing the privcollect payload before LiteLLM is explicitly imported in any Python session.
• Exfiltration targets include cloud tokens, developer accounts, private keys, AI credential JSON files, environment variables, and Chromium/Firefox browser data, sent via HTTP POST to litellm[.]dev/healthcheck.
• Default safe fallback identified in reporting is version 1.106.2; no confirmed government-system compromises have been reported.
• Hunt indicators: /tmp/.pc_once_* signals exfiltration occurred; /tmp/remote_code_loader.lock signals the C2 daemon ran or is still active.
• Contractors should rotate all secrets reachable by affected environments from a clean system and rebuild CI runners and containers rather than attempting surgical cleanup.
• Findings were reported by SafeDep, Socket, StepSecurity, Upwind, and Aikido Security, with commentary from malware hunter Ilyas Makari.