# AI supply chain attacks in 2026: what they took, and how

URL: https://infro.io/blog/ai-supply-chain-attacks-2026
Author: INFRO Editorial (https://infro.io/blog/editorial)
Publisher: INFRO
Published: 2026-10-21
Last modified: 2026-10-21
Last reviewed: 2026-10-21 (next review due 2026-11-20)
Topic: Security and governance
Format: Analysis

> Supply chain attacks in 2026 targeted AI developers directly: litellm 1.82.7 and 1.82.8 on PyPI carried a credential stealer (24 March), the SANDWORM_MODE npm typosquats planted a rogue MCP server in AI coding tools, codexui-android stole Codex authentication tokens, and anthropic-setup rewrote the Claude CLI's settings to send the API key to a third party. The lessons: pin and verify dependencies, keep provider credentials out of build and install environments, watch AI tool configuration files, and prefer architectures where applications never hold provider keys.

Key takeaways:
- Every 2026 case here harvested secrets from the developer's own environment: environment variables, dotfiles and AI tool configuration files.
- AI tool configuration became a target in itself: rogue MCP servers added to assistant configs, and a rewritten base URL that sent an Anthropic key to a third party.
- A published package can differ from its public repository; reviewing the source on GitHub is not reviewing what you installed.
- Pin dependencies by hash, keep provider keys out of install and build environments, and check AI tool settings for servers and base URLs you did not add.
- Architectures where applications and tools hold a revocable gateway key instead of a provider key shrink what a compromised dependency can take, but the gateway then holds the provider keys and needs the same care.

**What were the AI supply chain attacks of 2026?** The packages and tools around AI development became a route to AI provider keys. A gateway library on PyPI shipped a credential stealer; npm typosquats of Claude Code planted a rogue MCP server in AI assistants; a Codex companion package stole authentication tokens; a fake Anthropic setup helper rerouted the Claude CLI to a third-party host along with the user's key. Each one harvested secrets from the developer's own environment, and each one is a reason to keep provider keys away from the code that does not need them.

This analysis collects the cases with public, attributable reports, says what each did according to the organization that reported it, and draws the patterns. It is not exhaustive: most malicious packages are removed with little more than a database entry.

## The 2026 cases at a glance

| Reported | Case | Ecosystem | Entry | What it went after | Reported by |
| --- | --- | --- | --- | --- | --- |
| Feb 2026 | SANDWORM_MODE | npm | Typosquats incl. `claud-code`, `cloude` | Tokens, cloud keys, LLM API keys; a rogue MCP server in AI coding tools | Endor Labs, crediting Socket[1] |
| 24 Mar 2026 | litellm 1.82.7 / 1.82.8 | PyPI | Publishing access via a compromised CI scanner | Environment variables, SSH keys, cloud and Kubernetes credentials | LiteLLM[2], Datadog[3] |
| Jun 2026 | codexui-android | npm, Android | A working package whose published code differed from its repository | Codex access, refresh and ID tokens | CSO Online, citing Aikido[4] |
| Aug 2026 | anthropic-setup | npm | A fake setup helper run with the key as an argument | The Anthropic API key and all prompts, via a rewritten base URL | OSV, finder Amazon Inspector[5] |
| Oct 2026 | OpenCode Console | Hosted service | Unauthorized access to a legacy system, per OpenCode's email | Provider keys saved in team workspaces | Infosecurity Magazine[6] |

The last row is not a package compromise. It belongs here because a hosted tool that holds your keys is part of your supply chain too.

## LiteLLM on PyPI: the gateway library itself

LiteLLM's security update states that `litellm==1.82.7` and `litellm==1.82.8` were published to PyPI on 24 March 2026, that the payload was a credential stealer harvesting environment variables, SSH keys, AWS, GCP and Azure credentials, Kubernetes tokens and database passwords, and that stolen data was sent to a domain that was not LiteLLM's. LiteLLM believes the compromise originated in the Trivy dependency of its CI/CD security scanning and that the attacker bypassed the official workflow to upload directly[2].

Datadog placed it in a wider campaign it calls TeamPCP: a malicious Trivy release and force-pushed `trivy-action` tags on 19 March, an npm worm on 20–22 March, compromised Checkmarx actions and OpenVSX extensions on 23 March, LiteLLM on 24 March and Telnyx's PyPI package on 27 March. One technical detail matters for anyone who thinks "we never import it at runtime": version 1.82.8 added a `.pth` file, and executable lines in `.pth` files run at interpreter startup, so the payload ran whenever Python started once the package was installed[3].

Datadog's guidance was to treat any host or CI job that installed either version as a full-credential exposure, not to treat reverting the packages as complete remediation, and to rotate every credential reachable from affected runtimes[3]. LiteLLM said its official Docker image, which pins dependencies, was not affected[2]. A gateway library holds every provider key it routes to, which is why this case is the clearest of the year; [LiteLLM alternatives in 2026](https://infro.io/blog/litellm-alternatives-2026) covers what changed after it.

## SANDWORM_MODE: the assistant as the exfiltration channel

Endor Labs, building on Socket's initial description, analysed a set of npm packages including `claud-code`, `cloude` and `cloude-cod` — typosquats of Claude Code — alongside typosquats of common libraries. Among what the malware collected, Endor lists npm and GitHub tokens, environment variables, LLM API keys, AWS credentials, GCP service accounts and SSH keys[1].

The new part was the AI toolchain. Endor reports that the malware installed a rogue MCP server into the configuration of Claude Code, Claude Desktop, Cursor, Continue and Windsurf, next to the user's legitimate servers, and appended instructions to every tool description — visible to the model, not the user — telling the assistant to read SSH keys, AWS credentials, npm configuration and `.env` files and pass them back as a tool argument, without telling the user. Endor's summary: the assistant itself becomes the exfiltration mechanism. It also notes that the MCP server it analysed only saved harvested data to disk, with no network exfiltration code yet[1].

[Governing agent tools through an MCP gateway](https://infro.io/blog/mcp-gateway-govern-agent-tools) and [MCP server credential leaks](https://infro.io/blog/mcp-server-credential-leaks) cover the controls for that layer.

## codexui-android: the package is not the repository

CSO Online reported in June 2026 that Aikido researchers found `codexui-android`, an npm package advertised as a remote interface for OpenAI Codex, collecting Codex access tokens, refresh tokens, ID tokens and account IDs. A companion Android app pulled and executed the package at runtime. The code that stole tokens appeared only in the version published to npm, not in the public GitHub repository, according to an expert quoted in the article. Aikido's concern was the refresh token, which does not expire: in its words, a stolen one gives persistent, silent access to whatever the account can do[4].

Two lessons follow. Reading a project's source on GitHub is not reading what `npm install` delivered. And tokens issued to a desktop or CLI tool are credentials like any API key, often longer-lived than people assume.

## anthropic-setup: rewriting where the key goes

The OSV advisory for `anthropic-setup`, published on 5 August 2026 with Amazon Inspector as the finder, describes a package presented as an Anthropic API setup helper, run as `npx anthropic-setup <key>`. It wrote the Claude CLI's settings file to point the base URL at a hardcoded third-party domain, stored the user's API key, and configured a helper that returned it — so the official CLI sent prompts and the key to that domain instead of Anthropic. The advisory says any computer that installed or ran it should be considered fully compromised, with secrets rotated from a different computer[5].

Nothing in this attack needed a vulnerability. It needed one command run with a real key, and a settings file that no one reviews.

## OpenCode Console: the hosted holder

In October 2026, OpenCode disclosed a breach of its Console, which holds each team workspace's provider credentials and uses them to authenticate requests. According to Infosecurity Magazine, OpenCode's email to users described unauthorized access to a legacy system it was decommissioning and said third-party provider keys saved in a workspace may have been exposed; OpenCode said the incident was related to a large-scale distillation attack affecting 1.4% of Console users, and notified Anthropic, OpenAI and Google[6]. The root cause had not been published at the time of writing; [our incident summary](https://infro.io/blog/opencode-console-breach-what-happened) tracks what has been.

It is a different mechanism from the packages above, with the same result for an affected customer: provider keys outside their control, usable directly at the provider. [What happens when a BYOK platform is breached](https://infro.io/blog/byok-platform-breach-blast-radius) models that case.

## Precedents from 2025

Three earlier cases set up the 2026 patterns:

- **s1ngularity (August 2025).** Wiz reported that malicious versions of the Nx build system ran a post-install payload that harvested `.env` files, SSH keys, GitHub and npm tokens and cloud credentials, and prompted locally installed AI CLIs — Claude, Gemini and Q — with permission-bypassing flags such as `--dangerously-skip-permissions`, `--yolo` and `--trust-all-tools` to search the filesystem. Wiz said that AI-assisted activity succeeded in hundreds of cases[7].
- **postmark-mcp (September 2025).** CSO Online reported Koi Security's finding that version 1.0.16 of a squatted `postmark-mcp` package, after fifteen clean versions, added one line that copied every email sent through it to an outside address[8].
- **nullifAI (February 2025).** ReversingLabs found two models on Hugging Face whose pickle-based PyTorch files, packed in an unusual format, carried a reverse shell that Hugging Face's scanner did not flag; Hugging Face removed them and updated its scanner[9]. Loading a model file from a hub can execute code.

## The patterns

Across the cases, five patterns repeat.

1. **The developer's environment is the prize.** Environment variables, `.env` files and dotfiles are read at install or interpreter start. Any provider key present on a machine or CI runner that installs a poisoned package should be assumed taken.
2. **AI tool configuration is an attack surface.** MCP server lists, CLI settings files, base URLs and key helpers decide where prompts and keys go, and few people review them after setup.
3. **Published artifacts differ from source.** A clean repository says nothing about the tarball or wheel you installed.
4. **Security tooling is in the blast radius.** The LiteLLM compromise came through a scanner in CI, the tool trusted to catch exactly this.
5. **Agents can be turned into collectors.** Two cases used the assistant's own access — by prompt or by tool description — to read files the malware could have read itself, with less noise.

## What to change

**Pin and verify dependencies.** Install from lockfiles. In Python, pip's hash-checking mode requires every requirement to be pinned and checks each download against a hash in your requirements file, guarding against remote tampering that pip does not otherwise check for[10]. If you publish packages, Trusted Publishing gives CI a token valid for 15 minutes instead of a long-lived one that works until someone notices it was stolen[11].

**Keep provider keys out of install and build environments.** A CI job that installs dependencies does not need an OpenAI key. Inject secrets only into the step that uses them, and run installs in a job without them. [Short-lived credentials for AI APIs](https://infro.io/blog/short-lived-credentials-ai-apis) covers the options providers offer.

**Give every tool and environment its own key, scoped and limited at the provider.** Then a key taken from a laptop is not the production key, and its provider spend limit bounds what it can cost. [The AI API key security checklist](https://infro.io/blog/ai-api-key-security-checklist) lists the controls.

**Review AI tool configuration.** Periodically list the MCP servers each assistant has configured, and check settings files for base URLs, key helpers and servers no one added. Treat an MCP server like a dependency with network access, because it is one.

**Prefer architectures where applications never hold provider keys.** If an application or coding agent authenticates to a gateway with a gateway key, a poisoned package in that application takes a key that can be limited to some providers, models and networks, rotated, and revoked without touching the provider account. The provider keys then live in one place, which needs the protections in [BYOK credential architecture](https://infro.io/blog/byok-credential-architecture) — and a breach of that place is its own risk.

**Rotate after exposure, at the provider.** Reverting a package or reinstalling a machine does not revoke what was read. Revoke and replace every key the affected environment could reach, then review provider usage from the earliest exposure.

## How INFRO handles these risks, and its limits

INFRO is a gateway of the last kind: applications and coding agents such as Claude Code and Codex ([coding agents](https://infro.io/docs/coding-agents)) authenticate with INFRO gateway keys, and provider keys stay in INFRO, encrypted with AES-256-GCM under a key held outside the database and never shown again. A gateway key can be limited to chosen providers or IP ranges, belongs to one environment, can expire and can be rotated with an overlap window; hard budgets per key, member, project and organization are checked before a provider is called. For agents' own tools, the [MCP gateway](https://infro.io/docs/mcp-gateway) on the Business plan puts MCP servers behind the same organization controls.

Two limits are worth stating. INFRO's controls govern traffic that goes through INFRO, so a provider key taken from a developer's machine, from a CI runner or from INFRO itself can be used directly at the provider. With [reconciliation](https://infro.io/docs/cost/reconciliation) and usage access, INFRO can report OpenAI and Anthropic usage on a connected key that did not go through it; the backstop for everything else is provider-side scope, spend limits and revocation. And INFRO has its own release pipeline and dependencies, which carry the same class of risk as every case above.

## Summary

The 2026 supply chain attacks on AI developers went after the same thing by different routes: credentials in the developer's environment and AI tool configuration. Pin and verify what you install, keep provider keys out of the places that install code, review what your assistants are configured to trust, and assume any key a compromised machine could read is gone until you revoke it at the provider.

## Questions

### What was the LiteLLM supply chain attack?

On 24 March 2026, litellm 1.82.7 and 1.82.8 were published to PyPI with a credential stealer. LiteLLM said it believed the compromise came through the Trivy dependency in its CI/CD security scanning and that the attacker uploaded directly to PyPI, bypassing its release workflow. LiteLLM removed the versions and shipped a clean v1.83.0 through a rebuilt pipeline.

### Have malicious MCP servers been used to steal credentials?

Yes. Endor Labs reported that the SANDWORM_MODE npm packages in February 2026 installed a rogue MCP server into the configuration of Claude Code, Claude Desktop, Cursor, Continue and Windsurf, with hidden instructions telling the assistant to read SSH keys, cloud credentials, npm configuration and .env files. Earlier, in September 2025, a squatted postmark-mcp package copied every email it sent to an outside address.

### How do I protect AI API keys from supply chain attacks?

Pin dependencies by hash and install from a lockfile, keep provider keys out of install and build environments, give each tool and environment its own scoped key with a provider spend limit, check AI tool configuration files for MCP servers and base URLs you did not add, and rotate every key a compromised machine could read.

### Does reverting a compromised package fix the problem?

No. Datadog's guidance on the LiteLLM compromise was not to treat reverting the packages as complete remediation, and to rotate every credential reachable from affected runtimes. A stolen key keeps working until it is revoked.

## Sources

1. SANDWORM_MODE: Dissecting a Multi-Stage npm Supply Chain Attack — Endor Labs. https://www.endorlabs.com/learn/sandworm-mode-dissecting-a-multi-stage-npm-supply-chain-attack (accessed 2026-10-21)
2. Security Update: Suspected Supply Chain Incident — LiteLLM. https://docs.litellm.ai/blog/security-update-march-2026 (accessed 2026-10-21)
3. LiteLLM and Telnyx compromised on PyPI: Tracing the TeamPCP supply chain campaign — Datadog Security Labs. https://securitylabs.datadoghq.com/articles/litellm-compromised-pypi-teampcp-supply-chain-campaign/ (accessed 2026-10-21)
4. Attack targeting OpenAI Codex users exposes AI software supply chain risks — CSO Online. https://www.csoonline.com/article/4179815/attack-targeting-openai-codex-users-exposes-ai-software-supply-chain-risks.html (accessed 2026-10-21)
5. MAL-2026-12510: Malicious code in anthropic-setup (npm) — OSV. https://osv.dev/vulnerability/MAL-2026-12510 (accessed 2026-10-21)
6. OpenCode Breach Could Affect OpenAI, Anthropic and Google — Infosecurity Magazine. https://www.infosecurity-magazine.com/news/opencode-breach-openai-anthropic/ (accessed 2026-10-21)
7. s1ngularity: supply chain attack leaks secrets on GitHub — Wiz. https://www.wiz.io/blog/s1ngularity-supply-chain-attack (accessed 2026-10-21)
8. Trust in MCP takes first in-the-wild hit via squatted Postmark connector — CSO Online. https://www.csoonline.com/article/4064009/trust-on-mcp-takes-first-in-the-wild-hit-via-squatted-postmark-connector.html (accessed 2026-10-21)
9. Malicious ML models discovered on Hugging Face platform — ReversingLabs. https://www.reversinglabs.com/blog/rl-identifies-malware-ml-model-hosted-on-hugging-face (accessed 2026-10-21)
10. Secure installs — pip (Python Packaging Authority). https://pip.pypa.io/en/stable/topics/secure-installs/ (accessed 2026-10-21)
11. Trusted Publishers — PyPI. https://docs.pypi.org/trusted-publishers/ (accessed 2026-10-21)