LiteLLM Supply Chain Compromise on PyPI and Docker
LiteLLM Supply Chain Attack Steals Cloud and AI Service Keys
Related Entities
Organizations
Products & Tech
Full Report
Executive Summary
On October 21, 2026, the open-source AI gateway LiteLLM was the target of a significant supply chain attack, its second this year. Attackers compromised the project's release pipeline and published a malicious version, v1.107.0, to the PyPI package repository and Docker Hub. The trojanized package was engineered to steal a wide range of sensitive credentials from the environments where it was deployed, including cloud provider logins, developer secrets, and API keys for services like OpenAI and Anthropic. The malicious versions were active for several hours before being removed. Users and organizations are advised that simply updating is insufficient; a full rotation of all potentially exposed credentials is required.
Threat Overview
The attack represents a classic software supply chain compromise, where a trusted software distribution channel is used to deliver malware to downstream users. By compromising LiteLLM's release process, the attackers were able to push a malicious update that appeared legitimate. The malware's primary objective was credential harvesting, targeting high-value secrets commonly found in development and production environments that use AI services.
The malicious package was available during the following windows:
- PyPI (
litellm==1.107.0): October 21, 2026, from 11:39 to 13:23 UTC. - Docker Hub (tags
v1.107.0,latest,main-latest,main-stable): October 21, 2026, from 11:46 to 14:20 UTC.
The last known safe version prior to the incident is v1.106.2.
Technical Analysis
The attack leveraged a Compromise Software Dependencies and Development Tools (T1195.001) technique. Once the malicious package was installed, it executed code designed to scan the environment for credentials. This included searching for:
- Environment variables (e.g.,
AWS_ACCESS_KEY_ID,OPENAI_API_KEY). - Configuration files (e.g.,
~/.aws/credentials). - Secrets within CI/CD pipeline contexts.
After harvesting the credentials, the malware would exfiltrate them to an attacker-controlled server. The package also included capabilities to load remote-code execution tools, allowing for potential second-stage attacks and persistence in the compromised environment.
Impact Assessment
The impact of this supply chain attack is potentially severe for any organization that downloaded and deployed the malicious version. LiteLLM is a popular tool used to manage and standardize interactions with various large language models (LLMs). As such, it is often deployed in environments with access to highly sensitive data and powerful API keys.
Compromised credentials could allow attackers to:
- Access and steal data from cloud storage (e.g., AWS S3, Google Cloud Storage).
- Incur significant financial costs by abusing expensive AI service APIs.
- Gain a persistent foothold in the organization's cloud infrastructure.
- Pivot to other systems and escalate privileges.
The incident underscores the significant risks associated with relying on open-source packages without proper security controls like dependency pinning and verification.
IOCs — Directly from Articles
No specific C2 domains, IPs, or file hashes were provided in the source articles.
Cyber Observables — Hunting Hints
Security teams should hunt for evidence of the malicious LiteLLM version in their environments.
requirements.txt / pyproject.tomllitellm==1.107.0 to identify projects that may have installed the malicious version.CI/CD build logslitellm:1.107.0 or litellm:latest.CloudTrail, Azure Activity LogsDetection & Response
- Identify Installations: Immediately scan all systems, container registries, and source code repositories for any instance of LiteLLM version
1.107.0or Docker images pulled with the affected tags during the incident window. - Isolate and Analyze: Isolate any systems found to be running the malicious version. Conduct forensic analysis to determine the extent of the compromise.
- Assume Credential Compromise: As advised by security researchers, any organization that installed the malicious version must assume all credentials in that environment are compromised.
- Rotate All Secrets: Initiate a full rotation of all potentially exposed secrets. This includes AWS/GCP/Azure keys, AI service API keys (OpenAI, Anthropic, etc.), database passwords, and any other secrets present in the environment.
Mitigation
- Update to a Safe Version: Remove the malicious version and update to the latest secure version of LiteLLM (or downgrade to
v1.106.2or older if an immediate update is not possible). - Pin Dependencies: Implement dependency pinning in all projects. Instead of using
latesttags or flexible version ranges, pin to a specific, known-good version hash (e.g.,litellm==1.106.2). This prevents automatic updates to potentially malicious versions. - Vendor Dependencies: Use a private package repository (e.g., Artifactory, Nexus) to vet and host approved versions of open-source dependencies, rather than pulling directly from public registries.
- Least Privilege: Run applications and build jobs with the minimum necessary permissions. Use dedicated, short-lived credentials for CI/CD pipelines to limit the impact of a compromise.
Timeline of Events
MITRE ATT&CK Mitigations
Code Signing
Verify the integrity and authenticity of third-party packages before installation. While not foolproof, it can help detect tampering.
Run build processes and applications in isolated environments with minimal privileges and no access to long-lived production credentials.
D3FEND Defensive Countermeasures
To defend against future supply chain attacks like the one on LiteLLM, organizations should integrate dynamic analysis (sandboxing) into their CI/CD pipeline. Before a new or updated dependency is promoted to an internal artifact repository, it should be automatically installed and run in an isolated, instrumented environment. The sandbox would monitor for suspicious behaviors such as unexpected network connections, file system access outside of the package's scope, or attempts to read environment variables and secrets. If the package attempts to connect to an unknown external server, as the malicious LiteLLM package did, the build should be failed and a security alert generated. This provides an automated defense against trojanized dependencies.
A critical mitigation is to harden the configuration of dependency management tools. Instead of allowing developers to pull packages with 'latest' tags or broad version ranges (e.g., litellm>=1.100.0), enforce strict dependency pinning. This means specifying the exact, known-good version and its hash (e.g., litellm==1.106.2 --hash=sha256:...). This practice ensures that builds are reproducible and prevents the automatic introduction of a compromised package. Configure tools like pip and Docker to use an internal, trusted artifact repository (like Artifactory or Nexus) as the primary source, which only contains vetted and approved package versions. This breaks the direct link to public repositories where malicious packages can be uploaded.
Timeline of Events
Malicious LiteLLM version v1.107.0 is published to PyPI.
Corresponding malicious Docker images are pushed to Docker Hub.
Malicious package is removed from PyPI.
Malicious Docker images are removed from Docker Hub.
Sources & References
Article Author
Jason Gomes
• Cybersecurity PractitionerCybersecurity professional with over 10 years of specialized experience in security operations, threat intelligence, incident response, and security automation. Expertise spans SOAR/XSOAR orchestration, threat intelligence platforms, SIEM/UEBA analytics, and building cyber fusion centers. Background includes technical enablement, solution architecture for enterprise and government clients, and implementing security automation workflows across IR, TIP, and SOC use cases.
Editorial Standards & Analyst Review
CyberNetSec.io uses automation to assist source monitoring, deduplication, observable extraction, and structured intelligence generation. Published analysis follows human-defined editorial standards and adds defensive context including MITRE ATT&CK, D3FEND, STIX, and Sigma where applicable. Read our editorial policy.
Tags
📢 Share This Article
Help others stay informed about cybersecurity threats
🎯 MITRE ATT&CK Mapped
Every tactic, technique, and sub-technique used in this threat has been identified and mapped to the MITRE ATT&CK framework for consistent, actionable threat language.
🧠 Enriched & Analyzed
Observables and indicators of compromise (IOCs) have been extracted and cataloged. Risk has been assessed and correlated with known threat actors and historical campaigns.
🛡️ Actionable Guidance
Detection rules, incident response steps, and D3FEND-aligned mitigation strategies are included so your team can act on this intelligence immediately.
🔗 STIX Visualizer
Structured threat data is packaged as a STIX 2.1 bundle and can be visualized as an interactive graph — relationships between actors, malware, techniques, and indicators.
⚡ Sigma Generator
Sigma detection rules are derived from the threat techniques in this article and can be converted for deployment across any major SIEM or EDR platform.