LiteLLM Supply Chain Breach: How a Stolen OAuth Token Backdoored Your AI Stack
Executive Summary
In October 2026, LiteLLM version 1.107.0 was compromised in a software supply chain attack that injected a credential stealer (privcollect) and a persistent backdoor into PyPI wheels and Docker images. Threat actors exploited stolen GitHub CLI OAuth tokens to hijack three engineers' accounts, using one to trigger a malicious release pipeline and another to approve it. The malware executed automatically at Python interpreter startup via a rogue cook.pth file, harvesting cloud tokens, private keys, browser data, AI tooling credentials, and environment variables before exfiltrating them to attacker-controlled infrastructure. All affected packages have since been quarantined on PyPI.
This incident is the second confirmed supply chain compromise of LiteLLM within the same year, following the March 2026 TeamPCP campaign. The pattern signals that AI development tooling has become a high-value target for supply chain attackers, as a single compromised package can expose cloud credentials and model configurations across hundreds of downstream enterprise environments simultaneously.
Why This Matters Now
AI infrastructure packages like LiteLLM sit at the intersection of cloud credentials, LLM API keys, and production workloads, making them extraordinarily high-value supply chain targets. With two confirmed LiteLLM compromises in under eight months and attackers pivoting from OAuth token theft to automated CI/CD pipeline abuse, enterprises deploying AI gateways must treat open-source AI tooling with the same rigor as privileged infrastructure—enforcing egress controls, pinning dependencies by digest, and monitoring for anomalous outbound data transfers in real time.
Attack Path Analysis
Attackers compromised GitHub CLI OAuth tokens belonging to LiteLLM engineers, used those stolen tokens to authenticate into the GitHub Actions CI/CD pipeline, and injected malicious payloads (a credential stealer and a polling backdoor) into the LiteLLM 1.107.0 PyPI wheels and Docker images. Once installed by downstream developers and AI workloads, the malware harvested cloud credentials, private keys, browser data, and AI tooling secrets, packaged them into a GZIP TAR archive, and exfiltrated them via HTTP POST to an attacker-controlled domain, while simultaneously polling a GitHub dead-drop repository every hour to receive and execute arbitrary Python code.
Kill Chain Progression
This analysis maps confirmed threat intelligence to the full cloud kill chain to show where defensive gaps would emerge as an attack progresses.
Initial Compromise
Description
Threat actors obtained GitHub CLI OAuth tokens from at least three LiteLLM engineer accounts — the likely mechanism being token harvesting from developer environments, prior malware, or phishing — and used these valid credentials to authenticate to the LiteLLM GitHub organization without triggering standard login alerts. One account was used to trigger the project-releaser GitHub Actions workflow and a second account approved it, bypassing four-eyes review controls. Malicious code was injected into the PyPI build pipeline, producing tampered wheel files and Docker images published to PyPI as version 1.107.0.
MITRE ATT&CK® Techniques
Supply Chain Compromise: Compromise Software Dependencies and Development Tools
Compromise Client Software Binary
Unsecured Credentials: Credentials In Files
Steal Application Access Token
Exfiltration Over C2 Channel
Create or Modify System Process
Web Service: Bidirectional Communication
Command and Scripting Interpreter: Python
Potential Compliance Exposure
Mapping incident impact across multiple compliance frameworks.
NIST SP 800-53 Rev 5 – Provenance and Integrity of Third-Party Components
Control ID: SR-4
PCI DSS 4.0 – Software and Bespoke Development Security
Control ID: Requirement 6.3.2
DORA (Digital Operational Resilience Act) – Third-Party ICT Dependency Oversight
Control ID: Article 28 – ICT Third-Party Risk Management
NIS2 Directive – Supply Chain Security and Incident Handling
Control ID: Article 21 – Cybersecurity Risk Management Measures
CISA Zero Trust Maturity Model 2.0 – Software Integrity Verification and Least Privilege for CI/CD
Control ID: Applications Pillar – Application Security
ISO/IEC 27001:2022 – Supply Chain and Outsourced Software Assurance
Control ID: A.8.30 – Outsourced Development
Sector Implications
Industry-specific impact of the vulnerabilities, including operational, regulatory, and cloud security risks.
Information Technology/IT
LiteLLM supply chain compromise directly targets IT teams deploying AI infrastructure; stolen cloud credentials, private keys, and GitHub OAuth tokens enable lateral movement and exfiltration across multi-cloud environments.
Computer Software/Engineering
Software engineers consuming LiteLLM via PyPI face credential theft and backdoor implantation; compromised developer accounts and CI/CD pipeline abuse undermine zero trust segmentation and egress security controls.
Financial Services
Financial institutions using LiteLLM for AI-driven workflows risk credential exfiltration violating PCI 4.0 and NIST 800-53 controls, with browser data and authentication files harvested for unauthorized cloud access.
Health Care / Life Sciences
Healthcare AI deployments using LiteLLM expose HIPAA-regulated environments; stolen proxy credentials and model configurations enable unauthorized data access, violating HIPAA 164.312 encryption and access control requirements.
Sources
- LiteLLM Compromised in Supply Chain Attack Delivering Credential Stealer and Backdoorhttps://thehackernews.com/2026/10/litellm-compromised-in-supply-chain.htmlVerified
- LiteLLM 1.107.0 Compromised PyPI Backdoored Wheels Credential Stealer - StepSecurityhttps://www.stepsecurity.io/blog/litellm-1-107-0-compromised-pypi-backdoored-wheels-credential-stealerVerified
- LiteLLM Compromise - Socket Securityhttps://socket.dev/blog/litellm-compromiseVerified
- LiteLLM PyPI Compromise: Credential Stealer and Backdoor in sitecustomize.py - SafeDephttps://safedep.io/litellm-pypi-compromise-credential-stealer-backdoor/Verified
- LiteLLM 1.107.0 Supply Chain Attack: Malicious Code Found in PyPI Package - Upwindhttps://www.upwind.io/feed/litellm-1-107-0-supply-chain-attack-malicious-code-found-in-pypi-packageVerified
- LiteLLM GitHub Issue #47826 - Official Incident Response Statementhttps://github.com/BerriAI/litellm/issues/47826Verified
- LiteLLM PyPI Package History - Quarantine Recordhttps://pypi.org/project/litellm/#historyVerified
Frequently Asked Questions
Cloud Native Security Fabric Mitigations and ControlsCNSF
Based on the attack progression modeled above, these are the defensive controls that would constrain each stage.
Aviatrix Zero Trust CNSF is directly relevant to this supply chain incident because the malware's effectiveness depended entirely on unrestricted network reachability from compromised developer and CI/CD workloads into cloud environments, external C2 infrastructure, and exfiltration endpoints. By enforcing workload-level segmentation and FQDN-aware egress controls, CNSF would likely have reduced the attacker's ability to pivot across cloud boundaries and extract harvested credentials at scale.
Control: Cloud Native Security Fabric (CNSF)
Mitigation: CNSF fabric-level visibility could likely reduce the reachability of compromised CI/CD workloads to sensitive build and publishing infrastructure, constraining how far a token-authenticated attacker could move within the cloud-connected pipeline environment.
Control: Zero Trust Segmentation
Mitigation: Zero Trust segmentation would likely constrain the scope of privilege a compromised workload could exercise against adjacent cloud resources, reducing the blast radius even when host-level code execution has already occurred through the malicious package.
Control: East-West Traffic Security
Mitigation: East-west enforcement would likely reduce the attacker's ability to use harvested cloud credentials to move laterally between cloud workloads and service boundaries, constraining reachability across environments that share no legitimate operational need to communicate directly.
Control: Multicloud Visibility & Control
Mitigation: Multicloud visibility and FQDN-aware policy enforcement would likely reduce the attacker's ability to maintain reliable C2 polling from cloud-hosted workloads by surfacing anomalous outbound HTTPS calls to unexpected external domains and enabling policy-based restrictions on those paths.
Control: Egress Security & Policy Enforcement
Mitigation: FQDN-aware egress policy enforcement would likely reduce the success of disguised exfiltration attempts by constraining outbound HTTPS POST traffic to domains not explicitly included in approved egress allowlists, even when the destination mimics a legitimate operational endpoint.
Where prior CNSF controls constrained lateral movement, egress paths, and C2 polling, residual impact would likely be reduced to the individual compromised host scope rather than cascading across cloud environments, with harvested credentials finding fewer reachable targets due to segmentation-enforced access boundaries.
Impact at a Glance
Affected Business Functions
- AI/ML Development Pipelines and LLM Proxy Infrastructure
- Cloud Credential and Secrets Management
- CI/CD and Software Release Integrity
- Developer Toolchain and Authentication Systems
Estimated downtime: 3 days
Estimated loss: N/A
The malicious LiteLLM 1.107.0 package collected and exfiltrated a broad range of sensitive artifacts from affected developer and production environments. Exposed data categories include: cloud provider credentials and API tokens (AWS, GCP, Azure), private SSH and TLS keys, browser-stored credentials from Chromium and Firefox profiles, AI development tooling credential JSON files (e.g., OpenAI, Anthropic, Hugging Face API keys), environment variables containing secrets, LiteLLM proxy saved credentials and model configuration, and developer account authentication tokens. All collected data was compressed and transmitted via HTTP POST to a threat-actor-controlled endpoint. Any organization that installed LiteLLM 1.107.0 via PyPI wheels or Docker images before quarantine should assume full credential compromise across AI and cloud infrastructure.
Recommended Actions
Key Takeaways & Next Steps
- • Enforce egress FQDN filtering via Aviatrix Cloud Firewall (ACF) and Egress Security controls to block outbound HTTP POST to unrecognized or newly-registered domains such as litellm[.]dev/healthcheck and prevent credential archive exfiltration from cloud workloads and CI/CD runners; allowlist-only egress policies would have stopped the exfiltration stage entirely.
- • Deploy Multicloud Visibility & Control with anomaly baselining across all cloud workloads consuming LiteLLM to detect unusual outbound HTTPS POST patterns to novel FQDNs, hourly periodic polling behavior to GitHub repositories from application workloads, and large compressed archive transmissions inconsistent with normal LiteLLM proxy telemetry.
- • Apply Zero Trust Segmentation and East-West Traffic Security to constrain the blast radius of harvested credentials — microsegmentation policies tied to workload identity (pod, service account, or namespace) should prevent a compromised LiteLLM workload from accessing credential stores, cloud metadata APIs, or adjacent services beyond its minimum required scope.
- • Instrument Kubernetes Security (AKF) with namespace-level egress enforcement for all AI/LLM inference pods and developer toolchain containers; pod-to-internet egress should be restricted to approved AI API endpoints by FQDN, blocking both the dead-drop polling channel (github[.]com/letters9813) and the exfiltration endpoint without legitimate business justification.
- • Leverage Inline IPS (Suricata) with CNSF fabric-level real-time inspection to detect and block known supply chain payload signatures, malicious Python path-injection patterns (cook.pth / sitecustomize.py abuse), and outbound connections matching attacker infrastructure IOCs, complementing egress controls with signature-based prevention at the network layer for encrypted and unencrypted traffic flows.
