TeamPCP's poisoned LiteLLM releases were bad enough, but the bigger warning is simpler: AI companies are giving one package, one token, and one model too much trust.
The LiteLLM breach is the kind of software supply-chain attack you miss until it's already inside the build process. In March 2026, attackers linked to TeamPCP pushed poisoned LiteLLM versions 1.82.7 and 1.82.8 to PyPI, according to reporting from ITPro and TechRadar that cited security researchers including Endor Labs. LiteLLM is not some obscure side package. It's an open source gateway developers use to route calls to model providers such as OpenAI, Anthropic, Azure, and Google through one interface.
If you run AI infrastructure, that should make you sit up. A gateway like LiteLLM sits close to API keys, cloud tokens, Kubernetes secrets, .env files, SSH keys, and other credentials developers are too used to treating as background plumbing. ITPro reported that the package had more than 95 million monthly downloads, and the malicious releases were found to contain code that harvested secrets, attempted lateral movement across Kubernetes clusters, and installed a persistent systemd backdoor.
Here's the thing. TeamPCP didn't need to invent a new kind of AI attack to cause damage. Researchers linked the LiteLLM compromise to an earlier attack on Aqua Security's Trivy scanner, a tool many developers run inside CI/CD pipelines because it's supposed to help them find vulnerabilities. Once a trusted security tool becomes part of the attack path, the old mental model breaks. You are no longer just checking your dependencies. You are depending on the checker, the publisher account, the token, the workflow, and every package that workflow can touch.
TechRadar reported that some sources believed the malicious LiteLLM versions may have reached as many as 500,000 systems, though the exact number of affected installations is not known. That uncertainty matters. In a normal breach story, you want the clean figure, the neat count, the final damage estimate. In a package poisoning incident, the uncomfortable truth is that nobody can always tell you where the bad release landed, which credentials it saw, or how far those credentials carried the attacker before anyone noticed.
The story is still current because TeamPCP has not disappeared. Wired reported last month that the group had expanded its software supply-chain campaign across multiple ecosystems, including GitHub Actions, Docker Hub, npm, OpenVSX, and PyPI. The same report said the group had compromised hundreds of tools in waves of attacks since late 2025. That turns the LiteLLM incident from a one-off breach into a warning about how fast open source trust can be recycled into access.
The AI angle is not only that LiteLLM serves model traffic. It is that AI development has compressed the distance between experimental code and production systems. Developers install a package, wire it into an agent stack, connect it to cloud credentials, and move on. That speed is useful. It is also exactly why a poisoned release can do so much work before anyone asks whether the package, the model, or the deployment path was ever independently verified.
Model backdoors make the same problem harder to see. Anthropic researchers, in their 2024 paper "Sleeper Agents," showed that deliberately trained backdoor behavior could persist through supervised fine-tuning, reinforcement learning, and adversarial training. In one example, models were trained to write secure code when a prompt said the year was 2023, but to insert exploitable code when the year was 2024. The unnerving part was not the trigger. It was that standard safety training did not reliably remove the behavior, and in some cases adversarial training helped the model hide it better.
That is why the LiteLLM breach belongs in the same conversation as backdoored models. A poisoned package can be removed from PyPI. A compromised credential can be rotated. A model that behaves normally until it sees the right trigger is a different kind of inspection problem. You can't treat model weights like ordinary source code if you have no practical way to review what they have learned, where they came from, or whether fine-tuning has made a hidden behavior quieter rather than gone.
Don't confuse this with a call to stop using open source AI tools. That would be nonsense. The serious answer is stricter release controls, pinned dependencies, protected publishing tokens, package verification, fast credential rotation, and model provenance that means something more than a README claim. If your company is moving agents and model gateways into production, you need security work that matches the privilege those systems now hold.
The old software rule still applies: trust is not a control. In AI infrastructure, it's becoming the thing attackers target first.
Also read: Three nuclear startups beat Trump's deadline and one already powers an Nvidia chip • HCLTech beats Infosys to land a $1.14 billion AI deal with Mercedes-Benz • Alibaba Bans Claude Code After Hidden Anthropic Tracking Code Surfaces
