Bottom line: Attackers are deliberately compromising PyPI packages in AI toolchains because model weights, cloud tokens and CI/CD secrets are all accessible in one bundled location there.
On March 24, 2026, the group TeamPCP compromised the PyPI distribution of LiteLLM, a Python package with 95 million monthly downloads, and used it to distribute malicious code. The incident is emblematic of a series of attacks specifically targeting AI development environments.
TeamPCP gained access to the LiteLLM maintainer’s publishing credentials and released the manipulated versions 1.82.7 and 1.82.8. The payload was delivered via a .pth file – a little-known Python mechanism that automatically executes code every time the interpreter starts, without requiring an explicit import. According to Zscaler ThreatLabz, the poisoned packages were available for roughly three hours before being quarantined – enough time, per the source, to reach tens of thousands of enterprise environments. The multi-stage payload targeted AWS, GCP and Azure tokens, SSH keys, and cloud account credentials. According to ReversingLabs, the campaign was not limited to LiteLLM: TeamPCP had previously compromised trusted open-source security tools such as Aqua’s Trivy and Checkmarx KICS before moving on to AI infrastructure libraries on PyPI. In late April 2026, credential-stealing malware was also found in PyTorch Lightning versions 2.6.2 and 2.6.3, which executed upon import; a single malicious workflow file exposed secrets across entire CI/CD pipelines. ReversingLabs puts the increase in malicious open-source packages in 2026 at 73 percent.
For CISOs, this exacerbates a familiar risk within a specific environment: AI and ML development environments blend development, research, cloud infrastructure, data access, model publishing and automation within the same workspace. A compromised Python package in an ordinary web application will, in the worst case, steal a single database credential. The same attack in an AI development environment can simultaneously expose model weights, training data, cloud tokens from multiple providers, CI/CD pipeline secrets, and production API keys – all stemming from a single infected dependency. Compounding this is an attack vector known as slopsquatting: AI coding assistants frequently suggest pip-install commands and import statements for specific packages. If a developer trusts this recommendation and an attacker has already registered a malicious package under the corresponding name – sometimes a name hallucinated by the LLM itself – the attack succeeds without any direct interaction with the developer. Studies of nearly 200,000 Python prompts showed, according to the source, that every major LLM hallucinates package names that do not exist on PyPI, creating a persistent attack surface that cannot be fully closed by individual model updates.
As a concrete immediate measure, the article recommends pinning dependencies: instead of loose version specifications such as requests>=2.0, every dependency in AI development environments should be fixed to an exact version, with its checksum verified against a known hash. In the LiteLLM case, this alone would have limited the damage to environments that actively updated to the compromised versions, rather than affecting every environment that ran pip install litellm without version pinning. A second measure cited is auditing post-install hooks within the development pipeline, since such hooks – as in the LiteLLM case via the .pth mechanism – can automatically execute code without an explicit import.
Source: www.csoonline.com · Published August 7, 2026
Lumi AI News — AI-assisted curation pursuant to Art. 50 EU AI Act. Paraphrasing and classification by Lumi News Pipeline v1.8.3.