LiteLLM supply chain attack: 5 facts to check

Two PyPI releases, numbered 1.82.7 and 1.82.8, turned the LiteLLM supply chain attack from a warning into a real incident in March 2026. As reported in Andrej Karpathy's public post, a simple pip install of the compromised version was enough to exfiltrate SSH keys and AWS credentials from a developer machine.

What is LiteLLM and why the incident mattered

LiteLLM is a Python library and proxy that lets an application call many LLM providers, including OpenAI, Anthropic, Azure and AWS Bedrock, through one interface. That universal position is exactly why the LiteLLM supply chain attack on the package mattered so much to Python developers.

Because LiteLLM sits between an application and every major model provider, environments that install it tend to hold dense collections of secrets: provider API keys, SSH keys, cloud credentials and infrastructure configuration. Andrej Karpathy, co-founder of OpenAI and former head of AI at Tesla, amplified the disclosure in a public post describing it as software horror, and reported the package at roughly 97 million downloads per month. That figure comes from his post, not from an independent audit of PyPI statistics.

The scope problem went beyond direct installs. Projects that depended on LiteLLM as a transitive dependency were exposed too. DSPy, the framework for programming with language models, was cited as an example of a package that pulls LiteLLM in when you install it.

Which LiteLLM versions were malicious and when

The malicious releases were 1.82.7 and 1.82.8, published directly to PyPI by the attacker, according to the disclosure discussed in the video. The 1.82.8 release was described as the more dangerous of the two because it shipped a startup hook that executed without any import of the library.

Two details from the timeline stand out. First, these versions never passed through LiteLLM's official CI/CD pipeline on GitHub; they were uploaded straight to PyPI, which suggests the bypass was necessary because the pipeline would have flagged the payload. Second, the attacker-controlled receiving domain was reportedly registered on 23 March 2026, one day before the malicious release appeared, so it was created specifically for this operation rather than being a legitimate LiteLLM endpoint.

How the credential-stealing payload worked

The payload collected credentials automatically every time the Python interpreter started on an infected machine. The mechanism was a .pth file, named litellm_init.pth, which Python executes at interpreter startup. In practical terms, simply having version 1.82.8 installed in an environment was enough to trigger the code, because importing the package was not required.

The malicious logic hid inside base64-encoded content so that a casual reading of the source would reveal nothing meaningful. As described in the disclosure, harvested credentials and system information were encrypted, with the analysis naming AES-256-CBC, and sent in an HTTP POST to models.litellm.cloud, a domain that did not belong to LiteLLM. To anyone watching network traffic with a proxy, the request would look like a small heartbeat or keep-alive message carrying an opaque encrypted blob.

The list of what the payload targeted, as enumerated in the public warnings, included SSH keys, AWS, Azure and GCP tokens, Kubernetes configurations, shell history, SSL keys, crypto wallets and database passwords. Any of these in an environment variable or config file was fair game.

How the maintainer account was compromised

The LiteLLM team confirmed that the maintainer account fell through a leaked secret tied to Trivy, an open-source vulnerability and secret scanner. A security tool was, in effect, the vector that compromised the security of a package used across the AI ecosystem.

The account of the maintainer in question had been hacked, and the attackers used that access to publish the two malicious versions. The irony is direct but worth stating plainly: scanning tools exist to reduce supply chain risk, and in this case a credential associated with one became the entry point. The broader lesson from the incident is that maintainer accounts, and the tokens any tooling holds for them, are themselves part of the attack surface, and many open-source contributors still do not use two-factor authentication on package registries.

How the attack was discovered

A bug in the malware is what exposed it. Karpathy summarized the discovery in his post: the attack had a bug which led to its discovery. A developer working with Cursor, the AI-first code editor, was using an MCP plugin that pulled LiteLLM in as a transitive dependency. When version 1.82.8 was installed on the machine, the malicious code consumed enough RAM to crash the session.

That crash prompted the investigation that ended with the malicious .pth file and the exfiltration domain. The uncomfortable conclusion, drawn by Karpathy and echoed across the discussion, is that a slightly more efficient implementation, one without the memory bug, could plausibly have gone unnoticed for weeks while quietly harvesting credentials from Python environments everywhere.

What the LiteLLM attack means for your dependencies

The practical takeaway is that every install is a trust decision about an entire dependency tree. Karpathy's closing argument, that supply chain attacks are the scariest failure mode in modern software and that classical software engineering treats dependencies as an unqualified good, pushed a debate about whether small features should be copied instead of imported. You do not have to accept the strong version of that argument to act on the weaker one: audit what you install, and know that no scanner catches everything.

A defensible checklist for a team processing this incident:

1. Pin exact versions and use hash checking so an unexpected release of a dependency cannot silently enter your environment.
2. Audit transitive dependencies with tools such as pip-audit or Dependabot, understanding that LiteLLM arrived in some machines only through packages like DSPy.
3. Verify that releases come from a project's official CI/CD pipeline, and treat registry uploads that bypass it as suspect.
4. Enforce two-factor authentication on any account that can publish packages, including tokens held by scanners and automation.
5. Run vulnerability scanning in CI, as many enterprise pipelines already do, and add the registry-publishing path to the review.

None of these steps would have caught the attack on its own, since the malicious build never touched the official pipeline. Together they shrink the window between a compromise and its discovery, which in this incident was closed by luck rather than by tooling.

Frequently asked questions

• Which LiteLLM versions were malicious? Versions 1.82.7 and 1.82.8 of the PyPI package, published in late March 2026, contained the credential-stealing code. The disclosure identified 1.82.8 as the more dangerous release because it included the litellm_init.pth startup hook that executed without importing the library.

• Was I affected if I only installed LiteLLM but never imported it? Possibly. The malicious .pth file executed whenever the Python interpreter started, so installation in the environment was enough to trigger the payload. Anyone who installed the compromised versions on a machine with stored credentials should rotate SSH keys, cloud tokens and database passwords.

• Did LiteLLM's official build pipeline ship the malware? No. The malicious versions were uploaded directly to PyPI and never passed through the project's official CI/CD pipeline on GitHub, which is likely why automated checks in that pipeline never saw the payload.

• How did the LiteLLM attack get discovered? The malware had a memory bug. A developer using an MCP plugin inside Cursor installed the compromised version as a transitive dependency, the code exhausted the machine's RAM, and the crash led to the investigation that uncovered the exfiltration.

Turning incident write-ups into lasting documentation

An incident like this lives mostly in scattered posts, a video walkthrough and a fast-moving thread of corrections, which makes it hard for a team to keep an accurate written record of what actually happened. If you explain topics like this on YouTube, whether security postmortems, framework comparisons or engineering lessons, the same knowledge can work as a searchable article instead of staying buried in a timeline.

Skala Blog turns a YouTube video into a written article: paste the URL, the video is transcribed, and you get a structured draft you can edit and publish. For a story like the LiteLLM compromise, that means your explanation of the attack becomes documentation your readers and teammates can actually cite.

Source video