Your Code Trusts Strangers. Two Attacks Last Week Prove How Badly That Can Go

Modern software is built on trust. When a developer types “npm install axios” or “pip install litellm”, they're not starting from scratch. They're pulling in code written by someone else, often hundreds of thousands of contributors scattered across the open-source ecosystem.

That invisible trust layer is what makes modern development fast. It’s also what makes it fragile.

In the last week of March 2026, that trust was exploited twice. One of those attacks centered around a tool many AI developers rely on without a second thought.

What is LiteLLM, and why does it matter?

LiteLLM is a Python library that works like a universal adapter for AI. If your company is building an AI product, chatbot, search tool, or code assistant, you probably need to talk to models from OpenAI, Anthropic, Google, Mistral, and others. Each of them has a slightly different API, or a different way of sending and receiving requests. 

LiteLLM puts a single, clean interface in front of all of them. Instead of integrating with five different APIs, you integrate with one.

It downloads roughly 95 million times a month. Most developers using it don't even know they're using it. Why? Because it arrives as a dependency of a dependency, quietly doing its job in the background of their AI stack.

That invisibility is exactly what made LiteLLM a perfect target.

How the LiteLLM attack actually unfolded

This wasn't a smash-and-grab. It was a methodical, multi-step operation that started five days before the actual attack.

March 19: The real entry point, Trivy

Attackers from a group called TeamPCP compromised Trivy, an open source security scanner that LiteLLM uses inside its own build process to check for vulnerabilities. They exploited a flaw in Trivy's GitHub Actions workflow to steal a long-lived access token. 

Quietly. No alarms. They now had keys to the kingdom, including credentials that would let them publish to PyPI as a trusted maintainer.

March 23–24: Cascading to other projects

Using the same stolen infrastructure, TeamPCP hit two more targets: 

• Checkmarx KICS, an infrastructure scanning tool
• Telnyx, a communications library on PyPI

Each attack harvested more credentials, each one feeding the next. The pattern was becoming clear to researchers: this group was working systematically through the AI developer toolchain.

March 24, midday: LiteLLM 1.82.7 and 1.82.8 published

Using the stolen PyPI credentials, TeamPCP published two poisoned versions of LiteLLM. The malware hidden inside ran a three-stage operation: 

1. Harvest credentials, SSH keys, cloud tokens, Kubernetes secrets, .env files, and crypto wallets.
2. Attempt to spread laterally across connected systems.
3. Install a persistent backdoor that would phone home for instructions. 

All of this happened silently, the moment a developer ran pip install.

March 24, afternoon: Discovery and chaos

A researcher at a company called FutureSearch noticed something odd: his laptop was running out of RAM. After digging in, he found base64 encoded malicious code buried inside the package. 

He posted his findings publicly. Within an hour, the thread had spread across GitHub, Reddit, and Hacker News. In a darkly ironic twist, when developers began reporting the issue in LiteLLM's GitHub repository, the attackers using the hijacked maintainer account posted 88 bot comments and closed the issue as "not planned."

What to do if you were impacted

If you installed LiteLLM 1.82.7 or 1.82.8, treat the machine as fully compromised. Rotate every secret, API key, SSH key, cloud credential, and environment variable that was accessible on that system. Do not attempt to clean in place. Re-image from a known good backup.

What is Axios, and why does it matter even more?

If LiteLLM is deep in the AI developer world, Axios is everywhere. It's a JavaScript library that makes it easier for apps to talk to the internet. 

If you are sending a login request to a server, fetching your social media feed, or submitting a form, there's a good chance Axios is doing that work behind the scenes. It's present in roughly 80% of cloud and code environments, according to researchers at Wiz. 

It's downloaded over 100 million times per week. It's also a transitive dependency in thousands of other packages, which means even if your team never consciously installed Axios, there's a reasonable chance it's sitting somewhere inside your project right now, brought in by something else that needed it.

How the Axios attack unfolded

What made this attack notable was not how sophisticated it was, but how patient. The attackers did not simply compromise an account and publish malware. They spent eighteen hours setting the stage first.

Their opening move was to publish a clean, harmless-looking package to npm under a new account, establishing just enough of a publishing history to avoid triggering automated security flags. The next morning, they used that same package as the delivery vehicle for the actual attack. By then, it looked legitimate enough to pass a surface-level check.

The entry point was the account of Axios's lead maintainer. Once the attackers gained access, they changed the associated email address to lock him out, then published two backdoored versions of Axios. The malicious code did not live inside Axios itself. It was tucked inside that pre-staged dependency, which npm pulled in automatically alongside the main package. From there, it executed silently the moment any developer ran an install.

The speed of the fallout was striking. The first infected machine was recorded just 89 seconds after the malicious package went live. Automated build pipelines had already resolved and installed it before any human could have reasonably responded. The packages were removed within three hours, but by then, the damage had already propagated across a meaningful number of environments. To make matters worse, the malware cleaned up after itself so thoroughly that standard security audits run after the fact showed nothing unusual at all.

The maintainer later said he could not understand how it happened, given that he had two-factor authentication enabled on practically everything. The likely answer is a stale access token, an old credential from years prior that had never been rotated, that the attackers used to bypass the newer, more secure publishing process entirely. The old key still worked. And that was enough.

What both attacks have in common

On the surface, these look like two separate stories: different languages, ecosystems, attacker groups, and motives. TeamPCP appears financially motivated. UNC1069 is a state-linked espionage operation. But structurally, the attacks are almost identical, and that's the more alarming story.

• Both attacks got in through a trusted, adjacent system, not the target itself. Trivy was the door to LiteLLM. A stale npm token was the door to Axios. 
• Both published malicious versions using legitimate credentials, which meant the packages passed standard integrity checks because they were technically signed by the right account. 
• Both were live for about three hours and hit thousands of machines before anyone noticed.

The playbook is converging. Attackers have figured out that targeting the tools developers use to build software is dramatically more efficient than trying to hack individual companies one by one. You compromise one widely used library, and every company that builds with it becomes your attack surface.

"The package passes all standard integrity checks because the malicious content was published using legitimate credentials, not injected after the fact," writes Stephen Thoemmes.

Three lessons from the LiteLLM and Axios attacks

1. One compromised person = millions of affected machines. ‍

Both attacks started with a single person's credentials, a maintainer account, and a CI/CD token. In the Axios case, the maintainer even had two-factor authentication. It wasn't enough. The lesson isn't "use better passwords." It's that the entire ecosystem can cascade from one weak link in someone else's garage.

2. Popularity is the point, not a coincidence. 

Attackers didn't pick random libraries. They picked the ones everyone uses. Axios is present in roughly 80% of cloud environments. LiteLLM is downloaded 95 million times a month. The bigger the library, the bigger the blast radius. Obscurity used to offer some protection. That window is closing.

3. Three hours was enough. 

Both malicious packages were removed from their registries within about 3 hours. But the security firm, Huntress, saw the first infection on a monitored endpoint just 89 seconds after the Axios package was published. Automated build pipelines pulled it before any human could read the news. Removal doesn't equal safety for those who have already installed it.

The uncomfortable implication: Most organizations have no idea what third-party code is actually running in their builds right now, let alone who maintains it or whether that person's accounts are secure.

What the organizations that survived unscathed did differently

The teams that came through both incidents without incident shared a few common practices. 

1. They used lockfiles package lock.json, yarn.lock, or poetry.lock that pinned exact dependency versions. When a new malicious version appeared on the registry, their builds didn't automatically resolve to it, because they weren't set to pull "latest." They were pinned to a specific, known good hash.
2. Some had gone further and disabled postinstall scripts in their CI/CD pipelines, a setting that would have neutralized the Axios attack entirely, since the malware relied on npm's postinstall hook to execute. 
3. Others had provenance checks in place: Axios's legitimate releases always include build attestations that cryptographically link a published package to the specific GitHub Actions run that produced it. The malicious versions had none. Automated alerts for missing provenance would have flagged the poisoned package in seconds.

None of these practices is exotic. They're well documented, just not universal. And the gap between teams that have them and teams that don't is becoming the gap between teams that survive supply chain attacks and teams that don't.

The bigger picture

Software has always been built on trust. The open source ecosystem runs on the assumption that code shared freely, reviewed by many, and downloaded by millions is roughly safer than something proprietary and opaque. That assumption is being stress tested in a way it hasn't been before.

This isn't an argument against open source. The alternative, every company building everything itself, is worse in every imaginable way. But it is an argument for treating third-party dependencies the way mature organizations treat third-party vendors: with contracts, audits, monitoring, and a clear answer to the question "what happens if this supplier is compromised?"

Right now, most organizations don't have that answer. These two attacks are a preview of what happens when the question gets answered for you.