In the last week of March 2026, two of the most widely used open-source packages in software development were compromised by separate threat actors, seven days apart. The LiteLLM PyPI package was poisoned on March 24. The Axios npm package was backdoored on March 31. Together, the two attacks reached an estimated 500,000 machines, infected over 1,000 SaaS environments, and caused at least one $10 billion AI startup to lose 4 terabytes of data — including source code and contractor interview recordings.

Neither attack required a zero-day exploit. Neither required breaking through a firewall. Both succeeded by compromising something most security teams don't scan, monitor, or gate with the same rigor as their own code: the packages their developers install automatically, without thinking, every time they run pip install or npm install.

This is the supply chain problem in its current form — and it's getting worse, not better, because AI tooling has introduced a new class of high-value targets that didn't exist eighteen months ago.

The LiteLLM Attack: 40 Minutes, 97 Million Downloads, 1,000+ Victims

LiteLLM is an open-source Python library that provides a unified interface for calling over 100 large language model APIs. If your team has built any AI application that routes between OpenAI, Anthropic, Gemini, or any other provider, there's a reasonable chance LiteLLM is somewhere in your stack. It has 97 million monthly downloads on PyPI.

On March 24, 2026 at 10:39 UTC, malicious versions of the package — litellm==1.82.7 and litellm==1.82.8 — appeared on the Python Package Index. They contained credential-harvesting malware introduced by a threat actor tracked as TeamPCP. PyPI quarantined the packages approximately 40 minutes later.

Forty minutes. That is how long the window of active exposure was. In that window, any automated CI/CD pipeline, Docker build, or developer machine that fetched a fresh install of LiteLLM with a non-pinned version constraint would have received the malicious package. Given LiteLLM's download volume, that window was enough.

Threat intelligence firm vx-underground estimated that the attackers exfiltrated data and secrets from 500,000 machines. Mandiant's CTO Charles Carmakal confirmed to reporters that Google-owned incident response teams were engaged with "over 1,000 impacted SaaS environments" still dealing with cascading effects weeks after the initial compromise.

Mercor — a $10 billion AI recruiting startup — was among the victims. The company confirmed it was "one of thousands" affected. Extortion group Lapsus$, which appeared to have acquired data from TeamPCP, published samples of alleged Mercor data including Slack messages, internal ticketing records, and contractor interview recordings. Total claimed theft: 4 terabytes. Meta subsequently paused its work with Mercor as a precautionary measure while the breach investigation continued.

The Axios Attack: North Korea, Social Engineering, and 100 Million Weekly Downloads

Seven days later, a different attack hit a different ecosystem. Axios — the most popular JavaScript HTTP client, used in virtually every modern web and Node.js application — had its npm package compromised on March 31, 2026.

The mechanism was not a vulnerability in the Axios codebase. It was a social engineering campaign targeting a package maintainer, attributed by Google's Threat Intelligence Group (GTIG) to UNC1069, a financially motivated North Korean state-nexus threat actor active since at least 2018 and also tracked by Microsoft as Sapphire Sleet. The attacker gained maintainer-level access to the npm package and published two backdoored versions: axios@1.14.1 and axios@0.30.4.

The malicious versions introduced a dependency on a package called plain-crypto-js — an obfuscated dropper that deployed the WAVESHAPER.V2 backdoor across Windows, macOS, and Linux. Any project with a semver range of axios@^1.14.0 or axios@^0.30.0 would have pulled the compromised version on install or update.

The packages were live on npm from 00:21 to 03:20 UTC — just under three hours. Axios has over 100 million weekly downloads. Even a fraction of that volume during a three-hour window represents enormous potential reach.

Why AI Tooling Is the New High-Value Target

Both attacks targeted packages that sit at the intersection of AI development and widespread adoption. This is not coincidental.

LiteLLM is infrastructure-level tooling for AI applications. It handles API keys, routes requests to model providers, and sits between your application logic and your most sensitive external credentials. A credential harvester embedded in LiteLLM has direct access to exactly what attackers want: API keys for OpenAI, Anthropic, AWS Bedrock, and whatever else your AI stack is calling.

Axios is not AI-specific, but it is ubiquitous in the Node.js applications that increasingly serve as the frontend or API layer for AI systems. WAVESHAPER.V2 is a backdoor designed for persistent access and data exfiltration — a second-stage implant, not a smash-and-grab. The attackers weren't after quick credentials; they were establishing footholds for sustained access.

The pattern is consistent with what threat intelligence has been tracking for the past 18 months: state and financially motivated actors are specifically targeting developer toolchains because developers have privileged access to everything — production systems, customer data, model APIs, and internal infrastructure.

The Structural Problem: How Trust Gets Exploited

Open-source package registries like PyPI and npm operate on a model of implicit trust. When you add a dependency, you're trusting the package author, their account security, their development process, and every package in their dependency tree. You're also trusting that the registry itself will catch malicious uploads before they reach you.

That trust model breaks in three predictable ways:

Account takeover. If an attacker gains access to a maintainer's PyPI or npm account, they can publish any version they want. Password reuse, phishing, and social engineering are all viable paths. The Axios attack used social engineering specifically because it bypasses technical controls entirely — you can't patch human trust.

Typosquatting and package confusion. A package named litellm and one named litelllm look nearly identical in a requirements.txt file. Attackers routinely register variants of popular package names and wait for developers to make a typo. Automated dependency resolution can exacerbate this.

Dependency injection. The Axios attackers didn't modify the core library code directly — they introduced a malicious transitive dependency (plain-crypto-js). Security scanning tools that check direct dependencies often miss transitive ones. Your software bill of materials is only as complete as the depth of your dependency scan.

The window of exposure in both cases — 40 minutes and 3 hours respectively — illustrates the speed asymmetry. Registries have improved their malware detection, but detection is reactive. By the time a malicious package is quarantined, automated pipelines running worldwide have already fetched it.

What the Damage Profile Looks Like

The Mercor breach provides the clearest picture of downstream impact from the LiteLLM compromise. The attack chain looks roughly like this:

  1. LiteLLM malicious version fetched by a Mercor build pipeline or developer machine
  2. Credential harvester captures API keys, tokens, and secrets from the environment
  3. Stolen credentials provide access to downstream systems — Slack, internal ticketing, production databases
  4. Data exfiltration at scale (4TB) before detection
  5. Extortion attempt via Lapsus$, with data samples published as leverage

The timeline between initial compromise and detection is not public, but the fact that 4 terabytes were exfiltrated before Mercor issued a statement suggests hours to days of undetected access. That's consistent with what Mandiant observed across the broader LiteLLM victim set — cascading effects still being remediated weeks later.

For Mercor specifically, the business impact extended beyond the breach itself. Meta — a major client — paused work pending investigation. For an AI recruiting platform, that pause represents direct revenue impact from a single dependency being vulnerable for 40 minutes.

What Good Defense Actually Looks Like

Supply chain security is not a solved problem, but there are specific controls that would have materially reduced exposure in both attacks.

Pin exact versions in production

The fundamental control is version pinning. litellm==1.82.6 would not have fetched 1.82.7. axios@1.14.0 would not have fetched 1.14.1. Semver ranges like ^1.14.0 or >=1.82.0 exist for developer convenience; they are a security liability in CI/CD pipelines and production containers.

Pin everything. Update dependencies deliberately, not automatically. Yes, this creates maintenance overhead. The Mercor breach is a useful benchmark for what the alternative costs.

Verify integrity with hash checking

Both pip and npm support hash verification. pip install --require-hashes with a requirements.txt that includes SHA256 hashes will reject any package that doesn't match — regardless of what the registry serves. If the LiteLLM malicious version had a different hash than the pinned legitimate version (it would have), hash verification would have caught it at install time.

Generate and commit your lock files. For Python: use pip-compile with --generate-hashes. For Node: package-lock.json records resolved package integrity hashes — use npm ci instead of npm install in CI pipelines to enforce them.

Generate and maintain a Software Bill of Materials

You cannot respond to a supply chain incident if you don't know which systems are running which packages. A Software Bill of Materials (SBOM) — a machine-readable inventory of every package and version in every production system — is the prerequisite for answering "are we affected?" within minutes rather than days.

SBOM generation is now built into most modern build toolchains. CycloneDX and SPDX are the standard formats. Store them with your build artifacts and update them on every deployment. When the next LiteLLM-style event hits, you should be able to query your SBOM store and know your exposure in under five minutes.

Monitor for new versions of critical dependencies

Services like Dependabot, Renovate, and Socket.dev can alert you when new versions of your dependencies are published — including versions that exhibit anomalous behavior patterns (new network calls, obfuscated code, new dependencies). Socket.dev specifically flags supply chain risk signals at the package level and would have flagged the plain-crypto-js dependency introduced into Axios as suspicious before it reached production.

Restrict outbound network access from build environments

The WAVESHAPER.V2 backdoor deployed by the Axios attack connected to a command-and-control server on installation. A build environment with no outbound internet access — or one that allowlists only known registries — would have prevented the C2 callback even if the malicious package was fetched.

Most CI/CD pipelines have unrestricted outbound access because it's convenient. It's also what enables the second-stage payload delivery that makes these attacks persistent rather than contained.

Treat AI dependency packages as high-trust infrastructure

LiteLLM sits in your environment with access to every API key your AI stack uses. That's the same threat model as a secrets manager or an IAM service — infrastructure-tier, not application-tier. Packages at that level of access should be treated accordingly: vetted, pinned, hash-verified, and reviewed on every version bump.

The broader lesson is that AI tooling has created a new category of dependency risk. A malicious package in your logging library is bad. A malicious package in your LLM routing layer — which holds the keys to every external AI service you use — is potentially catastrophic.

The Pattern to Watch

Two attacks in seven days against two of the most critical packages in modern software development is not coincidence. It's evidence of a well-established attacker playbook being executed against a new and particularly valuable target set: the AI development toolchain.

The open-source ecosystem will not solve this problem at the registry level alone. PyPI and npm have improved detection dramatically since the SolarWinds era, but the window between publication and quarantine will never reach zero. The combination of automated pipelines, version ranges, and missing SBOM infrastructure means that a 40-minute window of exposure is enough to compromise thousands of organizations.

The controls are not complex. Pin your versions. Verify your hashes. Maintain your SBOM. Monitor your dependency tree. These are not new ideas — they've been best practices since at least 2020. The fact that Mercor and over a thousand other SaaS environments were still vulnerable to a 40-minute window suggests that most teams have deprioritized them in favor of moving fast.

The bill for that decision is now being calculated, four terabytes at a time.