Supply Chain SecurityAI SecuritySOC
The release pipeline of LiteLLM, the popular open-source proxy that many teams use to call multiple LLM providers, was compromised on 21 October 2026, and the malicious release steals credentials. According to BleepingComputer, the maintainers say the malicious version is 1.107.0, and that security firms including Socket and Endor Labs detected it within six minutes of publication. Customers on the private enterprise version were reportedly not affected.
litellm==1.107.0, all seven wheels, live from 11:39 to 13:23.v1.107.0, latest, main-latest and main-stable pointed to a malicious image from 11:46 to 14:20.ghcr.io/berriai/litellm, litellm-database and litellm-non_root were compromised from 11:46 until removal at 13:51.The window was short, but latest is what unpinned deployments, CI jobs and fresh pip install runs pull. If anything in your estate built or restarted from those tags in that period, treat it as exposed.
The attacker did not touch LiteLLM's application code. They changed only the installation package, adding three files to the Python library directory: cook.pth, cook.py and sitecustomize.py. Python processes .pth files at startup and imports sitecustomize, so the payload runs every time Python launches in that environment. That includes the Python or pip you run to investigate.
The malware targets:
.env files, and SSH, GPG and TLS keys.Stolen data is encrypted and uploaded to litellm[.]dev/healthcheck. For persistence, sitecustomize.py launches a detached loader that checks a GitHub-hosted pointer every hour, then downloads and runs further Python from an external server. Removing the package directory alone may leave the startup files and the running loader behind.
latest or main-* on 21 October.cook.* and sitecustomize.py files, hourly outbound connections to GitHub followed by a download from an unfamiliar host, and any traffic to litellm[.]dev.latest.BleepingComputer notes LiteLLM was also hit in March 2026, when the TeamPCP group published malicious versions after breaching a scanner used in its CI/CD pipeline. LLM proxies and gateways sit next to the most valuable secrets in an AI stack: every provider key, plus the cloud credentials of the box they run on. That makes them an efficient target. It is the same trust-once pattern we covered in the Rank Math PRO backdoor and the OpenCode key exposure: the artifact came from the expected source, so nobody looked again.
Pinning and scanning reduce the chance of installing a bad release. They do not tell you that one got through. This payload has observable behaviour: a process that reads credential files it has no reason to, an hourly beacon, and an upload to a domain nobody has seen before.
Obiguard SOC collects logs and host metrics through OpenTelemetry and makes them searchable in Live Logs by source and level. Alerts fire on rule matches and on log volume, and each alert keeps an evidence timeline linked to the raw events behind it. For an incident like this one, that means you can check which hosts made the outbound calls, when they started, and which ones to rebuild first.
To be clear about scope: SOC detects and records activity from the sources you send to it. It does not stop a malicious package from installing, and it only sees hosts that are forwarding telemetry.
If a trusted package began beaconing from one of your servers tonight, which log would show you the first call?
See how Obiguard SOC works or talk to us about monitoring the hosts that run your AI stack.
Obiguard sits in front of every AI request your organization makes — screening prompts and outputs against the guardrails, compliance frameworks, and audit trails that stories like this one make necessary.
See how it works →