Executive Summary
On October 21, 2026, attackers published a malicious LiteLLM 1.107.0 release to PyPI after abusing stolen developer GitHub credentials to hijack the upstream release workflow. The compromised wheel silently planted Python startup files—cook.pth, cook.py, and sitecustomize.py—outside the application directory, causing a credential-harvesting payload (PRIVCOLLECT) to execute automatically whenever Python initialized in any affected environment, including developer workstations, CI/CD agents, containers, and AI gateway hosts. Collected credentials were AES-256-CBC encrypted, RSA-key-wrapped, and exfiltrated to an attacker-controlled domain, while a secondary Unix loader enabled dynamic remote code execution via a GitHub-hosted dead-drop pointer.
This incident illustrates how a single compromised open-source dependency can silently harvest cloud credentials, AI model-provider API keys, SSH keys, and browser secrets across an entire organization's software supply chain—without the application ever being actively invoked. The growing reliance on AI gateway libraries like LiteLLM in production environments amplifies the blast radius significantly.
Why This Matters Now
AI infrastructure dependencies such as LiteLLM are now embedded in production pipelines across industries, making them high-value supply chain targets. The LiteLLM 1.107.0 compromise demonstrates that attackers are actively pursuing Python package ecosystems to silently steal cloud credentials and AI API keys at scale—a trend accelerating alongside enterprise AI adoption in 2026.
Attack Path Analysis
Attackers compromised upstream developer GitHub credentials to hijack the LiteLLM 1.107.0 release workflow, injecting malicious Python startup files (cook.pth, cook.py, sitecustomize.py) into the official PyPI package and container images. Once any affected environment started Python, the PRIVCOLLECT credential stealer executed automatically without requiring active LiteLLM use, harvesting cloud credentials, API keys, SSH/GPG material, browser data, and LiteLLM proxy database records, then encrypting and exfiltrating the collection to an attacker-controlled endpoint while a second Unix loader maintained a re-armable remote code execution channel via a GitHub-hosted dead-drop pointer.
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
Attacker obtained developer GitHub credentials through an undisclosed prior compromise, used them to redirect the LiteLLM release workflow from the legitimate BerriAI/litellm repository to the lookalike Berri-AI/litellm repository, and leveraged a second compromised developer credential to satisfy the production approval gate. The resulting malicious LiteLLM 1.107.0 wheel and container images containing cook.pth, cook.py, and sitecustomize.py were published to PyPI and distributed via official container registries, constituting a software supply chain compromise.
MITRE ATT&CK® Techniques
Supply Chain Compromise: Compromise Software Dependencies and Development Tools
Event Triggered Execution: Python Startup Hooks
Command and Scripting Interpreter: Python
Obfuscated Files or Information: Encrypted/Encoded File
Unsecured Credentials: Credentials In Files
Unsecured Credentials: Cloud Instance Metadata API
Credentials from Password Stores: Credentials from Web Browsers
Web Service: Dead Drop Resolver
Exfiltration Over C2 Channel
Data from Local System
Potential Compliance Exposure
Mapping incident impact across multiple compliance frameworks.
NIST SP 800-53 Rev 5 – Provenance and Integrity of Software Components
Control ID: SR-4
PCI DSS 4.0 – Software Inventory and Integrity of Payment-Related Scripts
Control ID: Requirement 6.3.2 / 6.4.3
NYDFS 23 NYCRR 500 – Application Security and Secure Development Practices
Control ID: 500.14(b)
DORA (EU 2022/2554) – Third-Party Software Supply Chain Due Diligence
Control ID: Article 28 – ICT Third-Party Risk Management
NIS2 Directive (EU 2022/2555) – Security of the Software Supply Chain
Control ID: Article 21(2)(d) – Supply Chain Security
CISA Zero Trust Maturity Model 2.0 – Least-Privilege Workload Identity and Outbound Access Controls
Control ID: Applications Pillar – Pillar 4: Application Access
ISO/IEC 27001:2022 – Outsourced Development and ICT Supply Chain Security
Control ID: Annex A 8.30 / A 5.21
Sector Implications
Industry-specific impact of the vulnerabilities, including operational, regulatory, and cloud security risks.
Information Technology/IT
LiteLLM 1.107.0 supply-chain infostealer targets Python environments, CI/CD pipelines, and cloud credentials, exploiting startup hooks to exfiltrate developer tokens, SSH keys, and workload identities without active package import.
Computer Software/Engineering
Compromised PyPI release weaponizes Python startup hooks against software build agents and developer workstations, stealing GitHub tokens, IDE credentials, and MCP integration secrets via automated credential harvesting before code executes.
Financial Services
Supply-chain infostealer targeting cloud credentials, database connection strings, and API keys exposes financial platforms to PCI 4.0 and NIST 800-53 compliance violations through uncontrolled lateral movement and encrypted credential exfiltration.
Health Care / Life Sciences
LiteLLM proxy deployments in healthcare AI infrastructure risk HIPAA 164.312 violations as the infostealer harvests cloud workload identities, database credentials, and environment variables through Python startup hooks on affected gateway hosts.
Sources
- Inside the LiteLLM 1.107.0 supply chain compromise: Credential theft through Python startup hookshttps://www.microsoft.com/en-us/security/blog/2026/10/23/inside-the-litellm-1-107-0-supply-chain-compromise-credential-theft-through-python-startup-hooks/Verified
- LiteLLM Contained: Oct 21 2026 LiteLLM release v1.107.0 Compromisedhttps://github.com/BerriAI/litellm/security/advisoriesVerified
- Python Software Foundation - Site-specific configuration hookhttps://docs.python.org/3/library/site.htmlVerified
- MITRE ATT&CK T1195.001 - Compromise Software Dependencies and Development Toolshttps://attack.mitre.org/techniques/T1195/001/Verified
- MITRE ATT&CK T1546.018 - Event Triggered Execution: Python Startup Hookshttps://attack.mitre.org/techniques/T1546/018/Verified
- CISA Known Exploited Vulnerabilities Cataloghttps://www.cisa.gov/known-exploited-vulnerabilities-catalogVerified
- Secure Software Supply Chain Practices - CISAhttps://www.cisa.gov/resources-tools/resources/securing-software-supply-chain-recommended-practices-guide-developersVerified
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 attack because the malicious LiteLLM payload depended on unrestricted outbound egress, open east-west paths between workloads, and uncontrolled access to cloud credential surfaces to complete its collection and exfiltration objectives. By enforcing segmented, identity-aware network boundaries across the affected cloud environments, CNSF would likely have reduced the attacker's ability to reach adjacent workloads and successfully transmit harvested credentials to external infrastructure.
Control: Cloud Native Security Fabric (CNSF)
Mitigation: CNSF fabric-level visibility across cloud workload ingress paths would likely reduce the reachability of attacker-controlled package sources by surfacing anomalous distribution patterns and limiting which environments can pull from unvalidated upstream registries, constraining the initial foothold's spread across production workloads.
Control: Zero Trust Segmentation
Mitigation: Zero Trust segmentation would likely constrain the scope of privilege abuse by ensuring workloads running the affected interpreter are confined to identity-scoped network segments, reducing their ability to reach adjacent credential stores, database endpoints, or internal services that sit outside the workload's defined trust boundary.
Control: East-West Traffic Security
Mitigation: East-west traffic enforcement would likely reduce the attacker's ability to move laterally across cloud workloads and Kubernetes environments by constraining which segments are reachable from a compromised process, limiting the scope of credential-based pivoting even after harvest material has been collected.
Control: Multicloud Visibility & Control
Mitigation: Multicloud visibility and centralized policy control would likely surface and constrain the periodic outbound beacon to raw.githubusercontent.com from production workloads that have no legitimate reason to poll external GitHub repositories, reducing the attacker's ability to maintain a reliable command channel across diverse cloud environments.
Control: Egress Security & Policy Enforcement
Mitigation: Egress security enforcement would likely reduce the attacker's ability to successfully transmit the encrypted credential archive to an external attacker-controlled endpoint by constraining outbound HTTP connections from workloads to a defined set of approved destinations, limiting the paths available for bulk data exfiltration even when the payload uses mimicry headers.
Where prior CNSF controls constrained east-west reachability and outbound egress paths, the residual impact to cloud workload identities, AI provider accounts, and pipeline secrets would likely be narrower in scope, reducing the number of downstream environments an attacker could pivot into using harvested material even after partial collection succeeded.
Impact at a Glance
Affected Business Functions
- AI Gateway and Model Provider API Integration
- Developer Workstation and CI/CD Pipeline Integrity
- Cloud Credential and Workload Identity Management
- Software Supply Chain and Package Distribution
Estimated downtime: 7 days
Estimated loss: N/A
The malicious package was capable of exfiltrating a broad range of sensitive credentials and configuration data from any environment where LiteLLM 1.107.0 was installed and Python was executed. This includes: model-provider API keys (OpenAI, Anthropic, Azure OpenAI, etc.) stored in LiteLLM proxy configuration; cloud provider credentials for AWS, Azure, and Google Cloud including metadata-service-derived tokens; Kubernetes service account tokens and Docker configuration; SSH private keys, GPG keys, and TLS certificates; CI/CD secrets and source-control tokens including GitHub, GitLab, and similar platforms; browser-stored credentials and session cookies from Chromium-family and Firefox browsers; AI coding tool tokens including GitHub Copilot and VS Code integrations; developer environment variables and dotenv files which may contain database connection strings or internal service secrets; LiteLLM proxy database records including stored provider credentials from LiteLLM_CredentialsTable and model routing parameters from LiteLLM_ProxyModelTable; and shell histories and database-client histories that may contain plaintext credentials. The collector ran automatically on startup across developer workstations, build agents, test systems, containers, and AI gateway hosts. A Unix-based remote code execution loader was also present, capable of fetching and executing arbitrary Python payloads from an attacker-controlled server, representing an ongoing post-compromise risk even after package removal.
Recommended Actions
Key Takeaways & Next Steps
- • Enforce egress filtering with FQDN/URL policy (Egress Security & Policy Enforcement / Cloud Firewall ACF): The PRIVCOLLECT payload exfiltrated data via HTTP POST to www[.]litellm[.]dev/healthcheck. Outbound traffic from developer workstations, CI/CD agents, containers, and AI gateway hosts should traverse a managed egress control that denies uncategorized or non-allowlisted destinations by FQDN, blocking exfiltration even when credentials were already collected.
- • Apply zero trust microsegmentation to workload and Kubernetes environments (Zero Trust Segmentation / Kubernetes Security AKF): Kubernetes service-account tokens, mounted secrets, and procfs process environments were in scope for collection. Pod-to-pod and namespace-level identity-based policy enforcement, combined with least-privilege workload identities, would have constrained the blast radius of the compromised package executing within a container or cluster context.
- • Instrument east-west and inter-workload traffic for anomaly detection (East-West Traffic Security / Multicloud Visibility & Control): The collector's access to AWS/Azure/GCP credential caches and metadata APIs, and the loader's background DNS resolution and outbound code retrieval, represent anomalous east-west and outbound behaviors. Centralized traffic observability with baselining across multi-cloud and hybrid environments would surface unexpected metadata API calls, cross-namespace credential reads, and covert loader polling.
- • Deploy inline IPS with supply-chain and malware signatures (Inline IPS Suricata / Cloud Native Security Fabric CNSF): The collector's OpenSSL staging under .pc_e_ prefixed temporary directories and the HTTP POST with a fixed browser-like User-Agent and X-SHA256 header are detectable behavioral patterns. Inline inspection with updated threat signatures covering known PyPI supply-chain stealer payloads, combined with real-time CNSF enforcement, would identify and block both the exfiltration attempt and the loader's /codepy retrieval request.
- • Encrypt all credential-bearing traffic in transit and enforce outbound TLS inspection (Encrypted Traffic HPE / Egress Security): The exfiltration channel used unencrypted HTTP (port 80) to www[.]litellm[.]dev/healthcheck. Mandating TLS for all outbound connections from production and developer environments, combined with egress TLS inspection and policy enforcement that rejects connections to uncategorized or newly registered domains, would have blocked or detected the plaintext exfiltration POST and the GitHub dead-drop polling request.



