LiteLLM Supply-Chain Attack Analysis

On March 23, 2026, LiteLLM -- a software component used by thousands of organizations around the world -- was compromised. For approximately 24 hours, any organization installing this component unknowingly received malicious code capable of stealing passwords, cloud service credentials and database access keys. Although Rosecape uses LiteLLM, we were not affected -- but we acted quickly to draw concrete lessons from the incident.

What happened

LiteLLM is an open-source tool that connects to multiple AI providers through a unified interface. On March 23, an attacker published two malicious versions on PyPI (the public Python package registry). The injected code performed two operations:

1. Silent collection of sensitive data from the machine: passwords, cloud service credentials, server access keys and command history
2. Exfiltration of this data to a server controlled by the attacker

The compromise was triggered at installation, with no visible signs.

A security tool as the entry point

What makes this attack particularly striking is its origin. LiteLLM's infrastructure used Trivy, a respected security scanning tool designed to detect software vulnerabilities. However, Trivy itself had been compromised a few days earlier.

On March 19, a group called TeamPCP injected malicious code into Trivy by exploiting flaws in automation mechanisms. For approximately three hours, organizations using Trivy in their automated processes had their credentials and access secrets silently collected.

This is exactly what happened to LiteLLM. Their automated validation process used Trivy to scan components. When the compromised Trivy ran in their pipeline, it collected LiteLLM's package publishing credentials. With these credentials, the attackers published malicious versions of LiteLLM directly to the public registry.

The same group exploited the stolen Trivy access to compromise packages on npm, Visual Studio Code extensions and Docker Hub images -- a coordinated campaign targeting multiple ecosystems simultaneously.

How we responded

On March 24, within hours of the public disclosure of the compromise, Rosecape had completed its investigation and secured all its environments.

Finding: Rosecape suffered no impact. Our deployment architecture freezes component versions at production release time; the compromised component was never installed.

Nevertheless, we applied preventive measures:

• Immediate shutdown of all internal services related to LiteLLM, with no impact on client data or environments
• Complete audit of every environment confirming that no compromised version had been installed
• Freeze on LiteLLM updates until publication of an independent security audit
• Preventive rotation of internal credentials as standard practice, despite no detected exposure
• Architectural workaround: modification of systems to communicate directly with AI providers, eliminating the LiteLLM dependency while maintaining functionality -- already in production with options under evaluation

This rapid response -- securing all systems within hours -- was possible thanks to complete visibility over our infrastructure: we knew exactly where components were deployed, their versions and their deployment contexts.

Why this attack is a wake-up call for SMEs

This attack did not exploit complex technical flaws, but rather the implicit trust in software tools. Even trust in security tools was turned against users.

This is a structural problem. Modern applications, including AI tools, rely on hundreds of components maintained by volunteer open-source communities. Compromising a single account reaches thousands of downstream organizations.

For SMEs, the risk is amplified through three current trends:

"Vibe coding": when AI writes your code without oversight

"Vibe coding" -- letting AI assistants generate code with minimal oversight -- is spreading rapidly. It's fast, productive and often impressive. But imagine this scenario: an employee asks an AI assistant to connect an application to multiple AI providers. The assistant logically suggests installing LiteLLM. The employee accepts with one click. If this had happened on March 23, 2026, all the machine's credentials would have been compromised.

The problem isn't the AI's suggestion -- it's the absence of a governance framework. When working at conversational speed with AI assistants, nobody stops to verify the reliability of a component.

Enterprise data analysis on unprotected machines

Another blind spot involves teams using AI tools to analyze enterprise data directly on workstations without dedicated environments.

The problem: these same workstations often contain access to all company systems -- saved passwords, server access, cloud service connections, database credentials.

When compromised code runs on such machines, it accesses everything. This was not a theoretical risk; this is exactly what the LiteLLM malicious code did: collect everything that was accessible.

The employee's natural reflex is to work where tools are already set up. But "convenient" rarely means "secure."

The invisible dependency on third-party components

Most SME executives don't know about LiteLLM or Trivy -- they're technical components, middleware layers. Yet the compromise of one led to the compromise of the other, potentially exposing the most sensitive data of any downstream organization.

This is the nature of supply-chain attacks: they hit blind spots -- not the monitored systems, but the tools your tools use, sometimes the security tools themselves.

What SMEs should do now

1. Isolate development and analysis environments

Never perform internal data analysis or AI development on machines with access to production credentials. Use isolated environments -- containers, virtual machines, dedicated workspaces -- where production secrets are simply not accessible.

2. Pin and verify dependencies

Don't trust "latest versions." Pin dependencies to specific, verified versions. For Docker images, use SHA identifiers rather than mutable tags like "latest" or "stable."

3. Establish guidelines for AI-assisted coding

Vibe coding isn't the problem -- it's the absence of a security policy around the practice. Establish clear rules: which packages can be installed, in which environments, with what level of oversight.

4. Inventory your critical dependencies

Do you know which open-source components power your AI tools? If not, now is the time to take inventory. You can't protect what you don't know about.

5. Plan your response before the incident

Our response time of just hours existed because we had visibility over our infrastructure -- we knew exactly where LiteLLM was deployed, its version and its deployment context. Without this visibility, an organization could spend days or weeks simply understanding whether it's affected.

Productive intelligence starts with mastery

This incident illustrates a recurring reality: technology only has value when it's mastered. AI is an extraordinary lever for SMEs, but only with solid foundations.

Rosecape's approach rests on principles that protected us here: controlled components, isolated environments, managed infrastructure hosted in Canada, and complete visibility over the supply chain.

To assess the security posture of your data and AI infrastructure, contact us.