On October 21, 2026, an attacker compromised the popular Python package LiteLLM, publishing version 1.107.0 to PyPI and pushing trojanized images to Docker Hub and GitHub Container Registry (GHCR). This is the second time we’ve seen an attack on LiteLLM, the first in March 2026.
If your organization pulled or installed litellm@1.107.0 on or after October 21, rotate your cloud credentials, SSH keys, browser sessions, and AI provider API keys immediately. The malicious release executed a credential stealer designed to exfiltrate secrets and query LiteLLM databases.
Here is what happened, how to check your environments for exposure, and how to block compromised packages automatically using Cloudsmith.
At 11:39 UTC on October 21, an attacker uploaded version 1.107.0 of LiteLLM to PyPI alongside compromised Docker tags (v1.107.0, latest, main-latest, and main-stable). The compromise occurred when stolen GitHub CLI OAuth tokens were used to access maintainer accounts, override branch protections, and trigger a release pipeline pointing to a lookalike repository.
Upon installation or execution, the package injects files into the Python site-packages directory (cook.pth, cook.py, and sitecustomize.py). These files execute automatically whenever the Python interpreter starts and deploy a credential stealer targeting:
~/.aws/ and IMDS metadata), GCP service account keys, Azure CLI tokens, SSH private keys, and GPG keys.SELECT * FROM "LiteLLM_CredentialsTable").The payload encrypted harvested secrets via AES-256-CBC and sent them to an attacker-controlled endpoint (www.litellm[.]dev/healthcheck). Active abuse was observed within hours, as attackers tested stolen AWS credentials against LLM foundation models.
Follow these steps to confirm exposure across your developer machines, repositories, and CI/CD runners:
Check dependency lockfiles: Audit your dependency manifests (requirements.txt, Pipfile.lock, poetry.lock, pyproject.toml) and active site-packages for version 1.107.0.
Check container images: Check for LiteLLM images pulled from Docker Hub or GHCR on October 21 (tags v1.107.0, latest, main-latest, and main-stable)
Locate packages in Cloudsmith: Search your Cloudsmith repositories with exact package names to avoid false positives (format:python) AND (name:^litellm$) AND (version:^1.107.0$)
Inspect Cloudsmith client logs: Review your Cloudsmith client logs to identify which developer machines or build agents fetched version 1.107.0. Check this even if the search returns nothing. Upstreams set to proxy only serve packages without storing them, so those packages won’t show up in search.
Remove installations and rotate secrets: If 1.107.0 ran in any environment, remove it immediately. Rotate all reachable AWS, GCP, Azure, and AI provider API keys, as well as SSH keys and database passwords. In Cloudsmith, quarantine the package rather than deleting it, so you keep the download history for your investigation
AI in the hand of attackers is compressing the supply chain lifecycle. Threat actors write malware faster, target AI tools directly, and reach pipelines through automated agents.
Attackers use LLMs to build malware faster: Wiz analysis noted strong indication of LLM–assisted code generation in the payload, allowing the attacker to iterate rapidly on multi-platform malware.
AI gateways are high-value targets: Packages like LiteLLM sit between applications and LLM providers. Compromise one and you reach upstream API keys, database credentials, and cloud infrastructure in a single step.
Agents install packages at machine speed: As engineering teams adopt autonomous AI coding tools and automated CI/CD pipelines, dependencies resolve faster than human review can keep up.
Public registries supply most of your dependencies, and they serve the ecosystem well. But pulling straight from public registries into builds means a malicious version of a package can reach you minutes after it’s published. Cloudsmith sits between public registries like PyPI and your developers and pipelines, acting as a central control point that protects you in three ways
Cooldown policies. Many package managers have client-side cooldowns, but they are hard to manage at scale. Cloudsmith enforces the cooldown at the repository level, so they work regardless of client version or script settings, by holding back newly published upstream versions for a defined time window (typically a few days). Attacks like LiteLLM 1.107.0 depend on speed: a malicious version is published, it gets pulled into builds within minutes, and then it’s withdrawn from the public registry.
Malicious package policies. These policies act on public reports to the OSV malicious packages repository and other sources. Cloudsmith scans packages and matches them against our consolidated database of malware advisories. Cloudsmith policy management helps you block versions flagged as malicious, or matching known indicators. Once a package is identified as compromised, the policy keeps it from reaching any endpoint client, even after a cooldown policy window. This eliminates the need to maintain a manual blocklist.
A single source of truth. Cloudsmith acts as the source of package dependencies for every developer, AI agent, and build pipeline across your company. As a central control plane that enforces controls, Cloudsmith produces a comprehensive audit trail of what entered your environment to answer questions like “Were we exposed?”.
If you'd like to understand your current exposure, book a demo with Cloudsmith for a custom assessment of your software supply chain.
