What happened
On March 24, 2026 at 10:52 UTC, version 1.82.8 of LiteLLM was published to PyPI. LiteLLM is a popular open-source Python library that acts as a unified API gateway across AI providers, letting developers switch between OpenAI, Anthropic, Google, and dozens of other models with a single interface. The library has become standard infrastructure for many AI teams.
The compromised version contained a malicious .pth file, litellm_init.pth, that executed automatically on every Python process startup. The payload ran in three stages: first it collected sensitive files from the host machine (SSH keys, .env files, AWS and GCP credentials, Kubernetes configs, database passwords, shell history, and crypto wallet files). Then it encrypted everything with a hardcoded RSA public key and sent it to a domain controlled by the attacker. Finally, if a Kubernetes service account token was present, the malware tried to create privileged pods across every node in the cluster and install a persistent backdoor.
The attack was discovered by FutureSearch, whose engineer noticed a runaway process storm on their machine and used AI tooling to trace it back to the malicious package. They disclosed publicly within hours of discovery. The compromised versions (1.82.7 and 1.82.8) were yanked from PyPI later that day. An estimated 47,000 machines may have downloaded the affected package during the window it was live.
Why this matters for enterprises
LiteLLM is not a fringe library. It is used widely in production AI stacks, including as a dependency inside tools like Cursor and various MCP plugins. Many organizations running AI agents or document processing pipelines have it installed without realizing it, often as a transitive dependency brought in by something else. That is exactly how it arrived on the FutureSearch machine: pulled in automatically by an MCP plugin.
The attack pattern targets exactly the assets that matter most in an AI deployment: cloud credentials, API keys, database passwords, and infrastructure configs. An attacker who gains those can pivot from a compromised developer laptop to your production environment, your CRM, your ERP, and your customer data. The blast radius of a compromised AI dependency is not limited to the AI system itself.
This incident also illustrates a deeper trend. As AI tooling matures, the attack surface grows. More dependencies, more integrations, more API keys sitting in .env files. Security teams that have not yet inventoried what their AI stack actually installs are operating blind. And with AI agents now routinely accessing document stores, email, and internal systems, the consequences of a credential leak are higher than they have ever been.
Laava's perspective
When we build AI integrations for clients, dependency management is part of the architecture conversation from day one. Not as a box-ticking exercise, but because the AI layer touches sensitive systems. An invoice processing agent has access to your ERP. A customer service agent can read your CRM. A document automation workflow handles contracts with real financial terms. Every one of those connections is a potential exposure point if the software stack underneath it is not controlled.
The LiteLLM incident is an argument for keeping your AI stack shallow and audited. Fewer transitive dependencies. Pinned versions with hash verification. Private package mirrors for production environments. These are not exotic measures: they are standard software supply chain hygiene applied to a new context. The AI ecosystem has moved fast and many teams have not caught up on the operational security side.
This is also one of the reasons we are cautious about recommending cloud-hosted AI infrastructure for clients handling sensitive data. When your AI workload runs in your own environment on infrastructure you control, the dependency surface is auditable and the blast radius of any compromise is contained. Sovereign AI is not just about data residency regulations: it is about knowing exactly what software is running near your most sensitive systems.
What you should do
If your team uses LiteLLM, check your installed version immediately with pip show litellm and verify you are not on 1.82.7 or 1.82.8. Inspect your package cache for litellm_init.pth. If you were affected, rotate all credentials that were present on the machine: cloud provider keys, API keys, database passwords, and SSH keys. Check for the persistence file at ~/.config/sysmon/sysmon.py.
More broadly, this is a good moment to run a dependency audit of your AI stack. What packages does your AI pipeline install? Which ones have access to credential files or cloud metadata? Can you pin and hash-verify your dependencies in production? If you are building on AI and these questions do not have clear answers yet, that is a gap worth closing. Laava can help you review and harden the architecture of your AI integrations so that the tooling that touches your most sensitive systems is the tooling you have deliberately chosen to trust.