LiteLLM, one of the most widely used open-source AI proxy libraries for routing calls across OpenAI, Anthropic, Google, and dozens of other LLM providers, has been compromised in a supply chain attack that injected malicious code into PyPI releases 1.82.7 and 1.82.8. The malware automatically exfiltrated approximately 300GB of data and 500,000 credentials from developer environments — including SSH keys, cloud provider credentials (AWS, GCP, Azure), Kubernetes configurations, database passwords, and Git tokens. The attack was discovered by developer Callum McMahon and confirmed by SlowMist Technology CISO 23pds, who issued an urgent warning to the cryptocurrency developer community. The malicious packages have been reported to PyPI.

What Happened

Attackers injected credential-harvesting malware into two consecutive LiteLLM PyPI releases: versions 1.82.7 and 1.82.8. Any developer or CI/CD pipeline that installed these versions automatically executed malware that collected sensitive files, encrypted the stolen data, and transmitted it to an attacker-controlled server at https://models.litellm.cloud/ — a domain deliberately crafted to blend in with legitimate LiteLLM infrastructure.

The attack operated in three distinct phases: collection, exfiltration, and persistence. After stealing and transmitting credentials, the malware attempted lateral movement within Kubernetes environments by spawning new pods with elevated system access — effectively turning each compromised developer environment into a staging point for further intrusion into production infrastructure. A bug in the malware's self-propagation logic triggered a fork bomb on affected systems, causing crashes that inadvertently revealed the attack to affected users before it could operate silently at full scale.

Developer Callum McMahon of FutureSearch identified the malicious releases and reported them to PyPI. Developer Daniel Hnyk subsequently filed a GitHub issue, broadening community awareness. SlowMist CISO 23pds issued an urgent public warning on X, urging immediate credential rotation and log auditing. Andrej Karpathy — co-founder of OpenAI and widely followed AI researcher — amplified the advisory, underscoring the systemic nature of the supply chain risk: "Every time you install any dependency you could be pulling in a poisoned package anywhere deep inside its entire dependency tree…The credentials that do get stolen in each attack can then be used to take over more accounts and compromise more packages."

What Was Taken

The malware conducted comprehensive credential harvesting from infected developer environments:

The 500,000 credential figure and 300GB volume indicates the attack achieved broad reach before detection — either through wide installation of the affected versions or through the malware's Kubernetes lateral movement spreading the collection beyond the initial infected host.

Why It Matters

LiteLLM sits at the center of the AI development stack. As a universal proxy for LLM API calls, LiteLLM is installed in development environments, CI/CD pipelines, production inference services, and research infrastructure across thousands of AI teams. Compromising it targets exactly the organizations building the next generation of AI-powered products — organizations that, by definition, have API keys for every major AI provider, cloud credentials for GPU compute infrastructure, and access to proprietary model training data and codebases.

Supply chain attacks against AI tooling are an emerging priority target class. This incident follows the Trivy supply chain attack and the TeamPCP/CanisterWorm campaign earlier in March 2026. The pattern is accelerating: attackers are specifically targeting the tooling that security-aware, technical teams use and trust. Developer tools command implicit trust — they run with the same permissions as the developer, in the same environment, with access to the same secrets. A poisoned package is a fully trusted insider.

The Kubernetes lateral movement capability is the most dangerous component. Most supply chain attacks stop at credential collection from the initial host. LiteLLM's malware attempted to propagate through Kubernetes clusters — meaning a single compromised developer laptop running a local k8s cluster could become a vector into production infrastructure. Organizations using LiteLLM in containerized production deployments face a materially different risk profile than those running it only in local dev environments.

500,000 credentials in attacker hands creates a multi-month exploitation window. Stolen cloud credentials, SSH keys, and database passwords don't expire automatically. Every set of credentials stolen in this attack remains valid until explicitly rotated. Organizations that installed the affected versions and have not yet rotated all credentials are operating with an unknown number of active attacker footholds — regardless of when the malicious packages were discovered and pulled.

The fork bomb self-disclosure was luck, not defense. The only reason this attack became widely known when it did is a bug in the attacker's own code. Without that malfunction, the malware may have continued silently collecting credentials across the LiteLLM install base for weeks or months. Organizations cannot rely on attacker errors to surface supply chain compromises.

The Attack Technique

The attack chain is fully documented:

  1. PyPI package poisoning — attackers published or compromised the release pipeline for LiteLLM versions 1.82.7 and 1.82.8, injecting malicious code into the PyPI distribution. This may represent a compromised maintainer account, a hijacked release pipeline, or a typosquatting/dependency confusion variant targeting LiteLLM's dependency chain.

  2. Automatic execution on install — Python package installation executes setup.py and post-install hooks automatically; the malware ran at install time without any additional user action required.

  3. Credential collection — the malware enumerated and collected SSH keys (~/.ssh/), cloud credential files (~/.aws/credentials, ~/.config/gcloud/, ~/.azure/), .env files, shell history, Kubernetes configs (~/.kube/config), and wallet files from the infected system.

  4. Encrypted exfiltration — collected files were encrypted and transmitted to https://models.litellm.cloud/ — a domain designed to appear legitimate in network traffic logs.

  5. Kubernetes lateral movement — the malware attempted to create new Kubernetes pods with privileged access, propagating beyond the initial host into any connected cluster infrastructure.

  6. Persistence via backdoor — hidden backdoors were installed to maintain access after the malicious package was removed, meaning simple package uninstallation does not fully remediate a compromised environment.

What Organizations Should Do

  1. Immediately determine if versions 1.82.7 or 1.82.8 were installed — treat any confirmed installation as a full compromise. Check all developer machines, CI/CD systems, Docker images, and production containers for LiteLLM installation history. Use pip show litellm and pip freeze outputs, container image history, and package manager logs. If either version was ever installed — even briefly — treat the entire environment as compromised and proceed to full credential rotation.

  2. Rotate every credential that existed on affected systems — no exceptions. SSH key pairs, AWS/GCP/Azure credentials and IAM access keys, GitHub/GitLab/Bitbucket tokens, Kubernetes service account tokens, database passwords, .env file secrets, and any API keys stored on the affected host must be rotated immediately. Do not selectively rotate — the malware collected broadly, and you cannot know exactly which files it accessed without a complete forensic review.

  3. Hunt for persistence mechanisms before declaring remediation complete. The malware installed backdoors designed to survive package removal. After rotating credentials and removing affected packages, conduct a full host forensic sweep: check for new cron jobs, systemd services, SSH authorized_keys additions, new user accounts, modified shell profiles (.bashrc, .zshrc, .profile), and any unfamiliar processes or network connections. Container environments should be rebuilt from clean base images rather than patched in place.

  4. Audit Kubernetes environments for unauthorized pods, service accounts, and cluster role bindings. If the affected system had kubectl access, assume the malware attempted cluster propagation. Run kubectl get pods --all-namespaces, kubectl get serviceaccounts --all-namespaces, and kubectl get clusterrolebindings — looking for any resources created around the time of the suspected compromise. Rotate all Kubernetes service account tokens and audit RBAC assignments.

  5. Implement package version pinning and hash verification in all CI/CD pipelines. The LiteLLM attack exploited the default behavior of installing the latest version of a package. Pin all production dependencies to specific, audited versions and enforce integrity verification using pip install --require-hashes with a verified requirements.txt. Integrate software composition analysis (SCA) tooling — Dependabot, Snyk, or Socket — into CI/CD pipelines to flag new or modified package releases before they reach developer or production environments.

  6. Isolate development environments from production credential access. Developer laptops and local environments should not have access to production cloud credentials, production database passwords, or production Kubernetes clusters. Enforce separation between dev and production IAM roles, use short-lived credentials with workload identity federation instead of static API keys, and ensure that a compromised developer machine cannot directly reach production systems. The LiteLLM attack's blast radius was amplified precisely because developer environments routinely hold production access.

Sources