Cloud, AI, and developer credentials may be compromised on systems that ran LiteLLM 1.107.0. Attackers inserted a credential stealer and remote-access backdoor into the release distributed through Python and Docker registries. The malware targeted browser data, cloud credentials, AI provider keys, SSH keys, and other secrets, then enabled remote command execution. The poisoned release was removed, but the number of affected systems remains unknown.
What Happened
Attackers compromised the LiteLLM release process and distributed a malicious version of the popular open-source AI gateway. Version 1.107.0 was made available through Python Package Index packages and official Docker images. The malicious version was uploaded at 11:39 UTC and was quarantined or removed from the relevant registries within hours.
The package contained both an information stealer and a remote-access backdoor. One malicious file caused the next stage to run automatically whenever Python started, without requiring further user action. The information stealer searched across 16 modules for browser credentials and cookies, AWS credentials, environment variables, instance metadata, Google Cloud service-account keys, application-default credentials, Microsoft Azure tokens, AI provider API keys, SSH private keys, GPG keys, and shell history.
A separate component started a background service that contacted attacker infrastructure every hour for new commands. This gave the attacker a continuing remote execution path on an infected machine.
Exposure was not limited to users who explicitly selected version 1.107.0. Docker users may have received the malicious image through the latest, main-latest, or main-stable tags. The most recent version identified as safe in the reporting was 1.106.2. The total number of affected systems remains unknown, even though LiteLLM receives about 23 million weekly downloads.
Why It Matters
LiteLLM provides a common interface to multiple large language model providers and may run beside AI API keys, cloud identities, database connection strings, and deployment credentials. That location gives a poisoned release access to secrets spanning several services rather than one application.
The malware also ran whenever Python started. As a result, exposure can extend beyond a single LiteLLM process to proxy containers, development systems, and continuous integration runners where the package was installed. The remote-access component creates a second concern because removing the original package does not prove that the environment was not changed afterward.
The package’s removal limits new exposure, but it does not recover credentials already collected. Response must therefore address both the affected hosts and every connected service whose secrets were present.
What to Watch
The scale of the incident remains unclear. Registry removal happened quickly, but the package was available through several distribution paths, including mutable Docker tags. Organizations should determine exposure from their own package records, container digests, deployment logs, and runtime evidence rather than waiting for a global victim count.
Investigators may release more information about the compromised release process and the systems behind it. Until then, attribution and the complete blast radius should be treated as unresolved.
Teams should also watch connected cloud, AI, source-control, and database services for activity involving credentials that were stored on exposed systems. Absence of the malicious package today does not show that secrets were never taken.
What Defenders Should Do
Immediate containment: Stop deployments of LiteLLM 1.107.0 and affected Docker images. Identify systems that pulled the version directly or through the latest, main-latest, or main-stable tags. Do not assume a mutable tag still points to the image that previously ran.
Host investigation: Examine every environment where Python executed after the package was installed, including proxy containers and continuous integration runners. Check for /tmp/.pc_once_* as an indication that exfiltration already ran and /tmp/remote_code_loader.lock as evidence that the command service ran or may still be running.
Credential response: Assume secrets accessible to the process may have been stolen. Rotate cloud credentials, AI provider keys, database passwords, private registry credentials, SSH keys, and other exposed secrets from a clean environment. Invalidate browser sessions where relevant because the malware also targeted cookies and stored browser credentials.
Recovery: Removing or downgrading the package is necessary but not sufficient. Investigate for follow-on commands or changes made through the remote-access component before returning systems to service. Use version 1.106.2 or another confirmed safe release while following updated project guidance.
The Larger Lesson
AI infrastructure increasingly concentrates credentials from multiple providers behind one convenient integration layer. That makes gateways, orchestration tools, and their release pipelines attractive supply-chain targets.
The incident also shows why package provenance and immutable releases matter. A trusted project name or official registry location cannot by itself establish that a specific artifact is safe. Organizations need records showing exactly which version or image digest ran and where it ran.
The durable lesson is to treat AI tooling like other privileged infrastructure. Limit the secrets available to it, track deployments precisely, and prepare to rotate credentials across several connected platforms when a dependency is poisoned.