LiteLLM, the open-source proxy library that enterprises use to route requests across OpenAI, Anthropic, Google and other model providers, has become the latest AI infrastructure package to be weaponized through its own release pipeline. Security firms SafeDep, Socket, StepSecurity and Upwind all confirmed that version 1.107.0, published to PyPI at roughly 11:39 UTC on October 21, contained a credential stealer and a remote-access trojan. The package counts about 23 million downloads a week, and the malicious release shipped both as PyPI wheels across seven platform builds and as official Docker images.
The technical design is what makes the incident severe. A file named cook.pth gets processed automatically whenever any Python interpreter starts, meaning the malicious code runs even if the host never imports LiteLLM. That loader executes cook.py, a stealer researchers identify as privcollect, which sweeps sixteen categories of data: browser credentials from Chrome, Firefox, Edge and Safari, AWS credentials, GCP service account keys, Azure CLI tokens, SSH and GPG keys, shell history, environment variables, and API keys for model providers including OpenAI, Anthropic and Cohere. It also targeted LiteLLM-specific material such as proxy credentials and model configuration. A third file, sitecustomize.py, spawns a background daemon that checked a GitHub dead drop every hour and executed attacker-supplied Python, giving operators a persistent channel that survived package removal.
Exfiltration was engineered to look routine. Stolen data was compressed, encrypted with AES-256-CBC and keyed with RSA-4096, then posted to www.litellm.dev under a /healthcheck path, a lookalike domain that blends into traffic logs. Researchers published host indicators, including files named /tmp/.pc_once_* and /tmp/remote_code_loader.lock, along with threat-hunting guides built around them.
The intrusion path is still being untangled. StepSecurity reports the attackers used GitHub CLI OAuth tokens stolen from the accounts of three LiteLLM engineers, with one account triggering the release workflow and another approving it. The working theory is that the tokens were harvested from the logs of an exposed internal LiteLLM deployment, though the project has not confirmed how access was obtained, a gap that matters because revoking known tokens closes the observed path without explaining the original breach. LiteLLM has since removed trusted GitHub links from public registries and restricted its organization membership.
Response was fast but imperfect. PyPI quarantined the package, malicious Docker images were pulled, and the involved OAuth tokens were revoked within hours. The projects guidance is blunt for anyone who installed 1.107.0: treat the host as compromised, roll back to 1.106.2 pinned by digest, revoke and rotate every credential that was reachable, and rebuild environments from known-good sources rather than attempting to clean them. The private enterprise registry was unaffected, and the source tag on GitHub did not contain the malicious files.
Context makes it worse. This is LiteLLMs second major incident this year, after a March 2026 compromise reportedly exposed more than 2,500 organizations and 434,000 CI/CD pipelines, and it is separate from the vulnerability disclosure Check Point published on October 15 and 16. AI tooling has become the highest-value dependency class in modern software precisely because a single proxy installation concentrates billable provider keys, cloud tokens and access to everything an AI workload touches. The lesson PyPI incidents keep teaching is that package removal is mitigation, not remediation, and for AI infrastructure the exposure window is measured in minutes at machine speed.
Comments (0)
Log in to join the discussion
Log InNo comments yet