AI Supply Chain Attacks Come Through the Plumbing

LiteLLM, a widely used open source gateway for routing requests across language model providers, was compromised twice in 2026. Malicious releases reached its public package registry in March and again in October, through two separate intrusions, each carrying a credential stealer into every environment that installed them.

‍

Neither attack touched a model. Neither one manipulated weights or tampered with training data. Both entered through the ordinary machinery that builds and ships software, and the AI stack was only what sat downstream. The same pattern runs through the other incidents examined below, which matters for where a security team should be looking.

‍

How the March Compromise Worked

‍

Through a chain of borrowed trust, with each step using a credential the previous one exposed.

‍

It Started With a Security Scanner

‍

The group tracked as TeamPCP first compromised Trivy, a widely used open source vulnerability scanner. LiteLLM's own build pipeline ran Trivy, so the poisoned scanner executed inside LiteLLM's continuous integration environment and captured the credentials used to publish packages.

‍

The Package Followed

‍

With those credentials, the attackers published versions 1.82.7 and 1.82.8 directly to the Python Package Index on 24 March, as LiteLLM's own advisory records. The releases were live for roughly forty minutes before being quarantined.

‍

Forty Minutes Was Enough

‍

Build pipelines install dependencies automatically and often with broad privileges, so a poisoned release spreads at the speed of automation rather than at the speed of a developer choosing it. A later reconstruction mapped potential exposure to more than two thousand organizations, which its authors stress describes exposure rather than confirmed compromise.

‍

Where the October Attack Began

‍

With an AI agent holding more access than anybody had decided to give it.

‍

A Key That Was Never Revoked

‍

In May, a configuration file committed to a public repository exposed the master key to LiteLLM's internal agent platform, a tool the team used to run agents that open pull requests. The mistake was caught and the commit removed, but the key itself was never revoked. It sat valid for nearly five months.

‍

An Agent With an Owner's Credentials

‍

The agent platform authenticated to GitHub with a token belonging to one of the organization's owners, issued to a person rather than a service account and never scoped down. When the attacker used the old master key on 10 October, the platform returned that token, and with it owner-level access to every repository the company held.

‍

How the Release Was Published

‍

The attacker used that access to collect further maintainer tokens, then redirected the release workflow to a lookalike repository one hyphen away from the real one. On 21 October it published version 1.107.0 to the package index for about two hours. Once inside, LiteLLM found the attacker's main interest was upstream inference API keys, the credentials that pay for model access.

‍

Why the October Release Reached So Far

‍

Because of where the malicious code chose to run.

‍

It Ran Without Being Called

‍

The release planted files in Python's startup path, so the stealer executed whenever Python started in an affected environment, whether or not LiteLLM was ever imported. Exposure reached any system where the package was installed, including machines that had no reason to run a language model gateway at all.

‍

Deleting the Package Did Not Remove It

‍

The startup files sat outside the package directory, so uninstalling LiteLLM left them in place. An organization that reacted to the advisory by removing the package could reasonably believe it had finished, while the stealer continued to run.

‍

What About Attacks on the Models Themselves?

‍

The closest cases still turn out to be code attacks rather than model attacks.

‍

Malicious Files on Model Hubs

‍

Researchers have found around a hundred malicious model files on public model hubs. Each carried a payload hidden in the serialization format many models are stored in, which executes arbitrary code at the moment the file is loaded.

‍

The Weights Did Nothing Unusual

‍

The model inside each file behaved normally. The attack was ordinary code riding in on a file format, so even the incidents that arrived looking like model attacks were software supply chain attacks underneath, and the wider category follows the same shape.

‍

Why Model-Focused Reviews Miss These

‍

The compromised component sits somewhere a model review never looks.

‍

It Lives in Code and Pipelines

‍

A gateway library sits in application code or a build runner rather than in a model registry. Data science teams frequently install these tools, platform engineering frequently never inventories them, and a review asking which models the organization uses has no reason to open the pipeline configuration at all.

‍

It Arrives Through Someone Else

‍

Most organizations caught in the March exposure had no relationship with LiteLLM. The library sat inside a supplier's stack, so a vendor assessment that never asked which open source components the supplier depended on could not have surfaced it. Three vendors resting on one dependency is the same structure seen from the procurement side.

‍

The Release Pipeline Is the Surface

‍

Even an accident follows this route. When a Claude Code release shipped with a file that should have been excluded, lookalike packages imitating its internal names appeared on the registry within a day. A packaging error became an attack surface without any adversary starting it.

‍

Agent Registries Are the Newer Front

‍

The same techniques, applied to the marketplaces where agents pick up new capabilities.

‍

A Poisoned Skill Marketplace

‍

The ClawHub registry distributes add-on skills for an open source agent framework. Antiy CERT counted at least 1,184 malicious skills that appeared on it, with a single author responsible for 677. They were disguised as trading tools and productivity helpers, and one documented sample read the agent's configuration file holding keys for paid AI services, the same credentials the October LiteLLM attacker went after.

‍

Trust Built Over Fifteen Releases

‍

In September 2025, an npm package imitating an official email integration for AI assistants shipped fifteen clean versions before the sixteenth added a single line that copied every outgoing email to the attacker. A history of good behavior was the cover rather than the warning.

‍

Skills Inherit the Agent's Reach

‍

A skill installed into an agent runs with whatever permissions the agent already holds, since it is not sandboxed separately. A poisoned skill reaches as far as the agent does, which makes the agent's own authority the thing that bounds the damage.

‍

What Holds Up

‍

The advisories converge on a short list, and most of it is ordinary software hygiene applied to a part of the estate nobody inventoried.

‍

• Pinned versions and digests: LiteLLM's exposure test covered unpinned installs and floating image tags, not pinned ones.
• Private registries where available: Customers pulling from LiteLLM's private enterprise registry were not affected by the October release.
• Developer tokens treated as high-value secrets: Command line tokens carried owner access in October without facing sensitive-action reauthentication.

‍

Rotation Has to Be Completed

‍

Both compromises turned on a credential that should have been revoked and was not. A key identified as exposed in May was still valid in October, so flagging an exposure without completing the rotation leaves the door exactly as open as before.

‍

Where Visibility Fits

‍

The question the morning an advisory lands is whether you are exposed, and where.

‍

Knowing What Is Installed and Where

‍

Removing a package from a public registry does nothing for the machines that already installed it, so the answer depends on knowing which AI components run in which environments. An organization that can answer that in an hour is in a different position from one that needs a week to find out.

‍

Knowing What Each Agent Can Reach

‍

The October attack started with an agent holding an owner's credentials that nobody had scoped. Visibility into which agents exist and what they hold is what makes it possible to set access controls that bound what a compromised component can touch, whichever package or skill turns out to be the next one.

‍

Look at the Plumbing

‍

LiteLLM was compromised twice in 2026, in March through a poisoned security scanner that exposed its publishing credentials and in October through an agent platform holding an owner's unscoped token behind a master key nobody revoked. Neither attack touched a model, and the closest model-layer cases on public hubs were code hidden in a file format. The compromised components sat in application code and build pipelines, often installed by data science and absent from any inventory, and frequently reached organizations through a supplier's stack. Pinned versions and private registries hold up, as do protected developer tokens and completed rotation, and knowing what is installed and what each agent can reach is what turns an advisory into a scoped response. What an AI bill of materials records covers the inventory side of the same problem.

‍

To see which AI components and agents reach your environment, and what each one holds, book a demo mapped to your own estate.