Executive Summary
On March 24, 2026, security researchers discovered that LiteLLM—a popular open-source AI proxy with roughly 97 million monthly PyPI downloads—had been compromised with credential-stealing malware. Versions 1.82.7 and 1.82.8 harvested every API key, cloud credential, and secret on every machine where they were installed. The attack is a defining case study in why AI gateways demand a fundamentally different security architecture than general-purpose libraries. This post examines the technical details, the architectural lessons, and the specific design decisions that make a secure, self-hosted enterprise data access platform like DreamFactory—which provides governed API access to any data source, connecting enterprise applications and on-prem LLMs with role-based access and identity passthrough—resilient against this entire class of attack.
LiteLLM serves as a unified proxy layer that routes API calls to over 100 LLM providers—OpenAI, Anthropic, Google, Azure, AWS Bedrock, and dozens more—through a single interface. It is a transitive dependency for major AI frameworks including DSPy, CrewAI, MLflow, and various LangChain integrations. Its position in the AI stack means it typically holds credentials for every LLM provider an organization uses.
The compromise was the latest strike in a coordinated campaign by a threat actor tracked as TeamPCP:
The attack used two delivery mechanisms across the compromised versions:
Version 1.82.7 embedded an obfuscated payload directly in proxy/proxy_server.py, which executed when the proxy module was imported.
Version 1.82.8 deployed a far more insidious technique: a .pth file (litellm_init.pth) placed in the Python site-packages directory. Python's site module automatically executes .pth files during interpreter initialization. No import statement was needed. Simply installing the package triggered the malware on every subsequent Python process.
Once triggered, the malware executed a three-stage attack:
models.litellm.cloud—a typosquat domain mimicking the legitimate litellm.aiThe entire LiteLLM package has since been pulled from PyPI—not just the compromised versions, but the entire package.
This was not a routine supply chain attack. It was a precision strike against a class of software that holds the keys to an organization's entire AI infrastructure.
Consider what a typical LiteLLM deployment centralizes:
An attacker who compromises an LLM proxy doesn't just get one key. They get all of them. And because these keys often carry broad permissions—generating completions, accessing embeddings, fine-tuning models—the blast radius extends far beyond simple API abuse.
Gartner projects that 40% of enterprise applications will embed AI agents by the end of 2026. Each agent needs API credentials. Each credential needs a management layer. The LiteLLM attack demonstrates what happens when that management layer becomes the single point of failure—and it runs as an open-source Python package with a transitive dependency chain reaching thousands of packages deep.
The core vulnerability was not a coding error. It was an architectural decision: storing and accessing LLM provider credentials inside a Python package that is installed, updated, and resolved through a public package registry.
This creates three compounding risks:
LiteLLM is installed via pip install litellm. That single command resolves dozens of transitive dependencies, each of which is a potential attack vector. The package is also pulled as a transitive dependency by DSPy, CrewAI, and others—meaning developers may not even know they've installed it. When any link in this chain is compromised, every credential accessible to the process is at risk.
LiteLLM's standard configuration pattern requires setting API keys as environment variables (OPENAI_API_KEY, ANTHROPIC_API_KEY, etc.) or passing them in configuration files on the same machine. Any process running on that machine—including malicious code injected through a supply chain attack—can read these values. The malware explicitly targeted environment variables because it knew exactly what it would find.
LiteLLM releases frequently. Teams that follow the common practice of pulling the latest version in CI/CD pipelines or Docker builds automatically consumed the malicious versions. The attack was discovered within hours, but with 3.6 million daily downloads, the exposure window was significant.
DreamFactory's architecture is designed around a principle that directly addresses the class of vulnerability exposed by the LiteLLM attack: credentials are managed server-side, stored encrypted in your own infrastructure, and never exposed to client applications, dependency chains, or environment variables on developer machines.
DreamFactory runs on your infrastructure—on-premises, in your private cloud, or in your own VPC. There is no SaaS intermediary. Credential storage, encryption, and access control all happen within your security perimeter. A compromised PyPI package on a developer's laptop cannot reach credentials that exist only inside your hardened server environment.
DreamFactory is a self-contained platform deployed as a complete application, not a library installed via pip or npm into a shared Python or Node environment. The credential management layer has no dependency on public package registries. There is no transitive dependency chain that an attacker can exploit to inject code into the credential handling path.
API keys, database passwords, and service credentials are stored encrypted in DreamFactory's system database. Integration with AWS KMS and Azure Key Vault enables organizations to manage encryption keys using their existing key management infrastructure. Credentials are decrypted only at the moment of use, server-side, and are never written to environment variables, configuration files, or logs.
DreamFactory enforces RBAC at the service, endpoint, table, and field levels. When an AI agent or application accesses data through DreamFactory's MCP Server or REST APIs, it authenticates with a DreamFactory API key that maps to a specific role. That role determines exactly which services, endpoints, and data fields are accessible. The underlying provider credentials (database passwords, cloud service keys) are never exposed to the calling application.
DreamFactory integrates with Azure AD/Entra ID, Okta, LDAP, and SAML providers to synchronize permissions automatically. When an employee's role changes in your identity provider, their API access permissions update accordingly. This eliminates the credential sprawl that makes supply chain attacks so devastating—there are no orphaned API keys sitting in environment variables across dozens of developer machines.
Whether or not your organization was directly affected by the compromised versions, this incident demands immediate action:
pip show litellm | grep Version across all environments—developer machines, CI/CD runners, staging, and productionfind / -name "litellm_init.pth" 2>/dev/null on any system where LiteLLM was ever installedmodels.litellm.cloudlitellm directly, or is it a transitive dependency of DSPy, CrewAI, or another framework?DreamFactory was not designed as a response to the LiteLLM attack. But its architecture—self-hosted deployment, server-side encrypted credential storage, no public package registry dependencies in the credential path, granular RBAC, and enterprise identity integration—directly addresses the systemic weaknesses this attack exploited.
With the MCP Server integration introduced in DreamFactory 7.4.0, organizations can expose their existing APIs to AI agents and LLMs without distributing credentials to client applications. The AI agent authenticates with DreamFactory. DreamFactory authenticates with the data source or LLM provider. The provider credentials never leave the server.
This architecture has been validated across 50,000+ production instances processing over 2 billion daily API calls, in industries including healthcare, financial services, government, and manufacturing—environments where credential compromise is not an abstract risk but a regulatory and operational imperative.
The LiteLLM attack is a signal, not an anomaly. As AI infrastructure becomes more central to enterprise operations, the tools that manage AI credentials will face increasingly sophisticated attacks. The question isn't whether your AI gateway will be targeted—it's whether your architecture can withstand it when it is.
LiteLLM versions 1.82.7 and 1.82.8 published to PyPI on March 24, 2026, contained credential-stealing malware. The attack was part of a coordinated campaign by the TeamPCP threat actor that first compromised Trivy and Checkmarx GitHub Actions. The malicious code harvested SSH keys, cloud credentials (AWS, GCP, Azure), Kubernetes configs, database passwords, environment variables (including all LLM API keys), and more. The data was encrypted and exfiltrated to a typosquat domain. The entire LiteLLM package has been pulled from PyPI.
DreamFactory is a self-hosted platform providing governed API access to any data source for enterprise apps and local LLMs. Because it deploys as a self-contained application on your own infrastructure—rather than as a library installed from a public package registry—there is no transitive dependency chain that attackers can exploit to inject code into the credential management path. Credentials are stored encrypted in your own database, integrated with AWS KMS or Azure Key Vault, and never exposed to client applications or environment variables.
DreamFactory serves a different primary function than LiteLLM—it generates governed REST APIs from databases and enterprise data sources, rather than acting as a multi-model LLM routing proxy. However, DreamFactory's MCP Server integration enables AI agents to access enterprise data through secure, role-controlled APIs without credential exposure. For organizations that need both LLM routing and secure data access, DreamFactory handles the data access layer with enterprise-grade security while LLM routing can be handled separately through provider SDKs or alternative gateways.
Assume full credential compromise. Rotate every API key, cloud credential, SSH key, and database password on every affected machine. Search for the persistence mechanism (litellm_init.pth) and any Kubernetes backdoors. Audit outbound network connections to models.litellm.cloud. Review CI/CD pipelines that may have pulled the compromised version automatically. Consider this a full security incident requiring forensic review.
LiteLLM is a transitive dependency of several major AI frameworks, including DSPy, CrewAI, and various LangChain integrations. If these frameworks resolved LiteLLM during the window when compromised versions were available on PyPI, they may have pulled the malicious code. Check your dependency lockfiles and installed package versions across all environments.
Traditional API vulnerabilities—injection, broken authentication, misconfigured CORS—exploit weaknesses in the API itself. The LiteLLM attack is fundamentally different: it exploited the software supply chain to steal credentials before they ever reached an API. This is why architectural decisions about where and how credentials are stored matter more than any individual security patch. A platform that stores credentials server-side in encrypted storage, isolated from client-side dependency chains, is resilient against this entire category of attack.