LiteLLM 供应链投毒：PyPI 上 1.82.7 与 1.82.8 被植入凭据窃取载荷，上游 CI 流水线所用的 Trivy 扫描工具先被攻破。 一句话（英）：LiteLLM supply chain poisoning: versions 1.82.7 and 1.82.8 on PyPI carried a credential stealer, after the Trivy scanner used in its CI pipeline was compromised first.LiteLLM supply chain poisoning: versions 1.82.7 and 1.82.8 on PyPI carried a credential stealer, after the Trivy scanner used in its CI pipeline was compromised first.

On March 24, 2026, an attacker published poisoned LiteLLM versions 1.82.7 and 1.82.8 directly to PyPI, bypassing GitHub's normal release flow; no tags for these versions exist on GitHub and the official source was not contaminated (BerriAI's official disclosure). Per BerriAI's official security update page, the affected window for pip installs ran from 10:39 to 16:00 UTC on March 24 (the two versions were published at 10:39 and 10:52 UTC, per Snyk's analysis, matching the window's start), and any environment that installed either version was in scope. The payload was a credential stealer: it scanned environment variables, SSH keys, AWS, GCP and Azure credentials, Kubernetes tokens, database passwords and more, encrypted them and sent them to models.litellm.cloud, a domain that is not BerriAI's. The two versions injected differently: 1.82.7 embedded the payload in Base64 inside proxy_server.py, triggered on importing the proxy module; 1.82.8 added a litellm_init.pth file that executed on every Python interpreter start in that environment (StepSecurity static analysis). The upstream chain, per vendor analyses by Endor Labs and StepSecurity: the attacker group TeamPCP first compromised the Trivy security scanner (aquasecurity/trivy-action) used in LiteLLM's CI pipeline, obtained the PyPI publishing credentials and took over the maintainer account to publish the poisoned versions; BerriAI's official disclosure confirms the poisoning came through the Trivy dependency. The poisoned versions were later deleted, maintainer accounts and keys were fully rotated, and BerriAI says Mandiant was engaged (pinned update on the official status thread). Unaffected paths: the official LiteLLM Proxy Docker image (pinned dependencies), installs from GitHub source, and version 1.82.6 and earlier (official security update page). The PyPA advisory database recorded the case as PYSEC-2026-2. Other sources put the exposure window anywhere between about 40 minutes and about 5 hours; this entry uses only the official affected window.

A tool layer failure: LiteLLM is a gateway style tool that centrally holds model API keys for many providers, so poisoning its own release pipeline delivered the stealer into every auto upgrading environment, and the .pth mechanism detached the payload from whether the library was ever called, making it resident at every Python start. On the platform gate, the publishing credential hung on a single third party scanner inside CI; once the upstream broke, the whole chain fell. Attribution note: the TeamPCP attribution comes from security vendor analysis and is recorded as an attribution position, not a judicial or official finding.

No single point for release credentials：publishing credentials cannot hang on one third party tool inside CI; once the upstream breaks, the whole chain falls.

Verify upstream tools first：the security scanner inside CI itself needs pinned versions and provenance checks.

Auto-upgrades need a brake：auto-upgrading environments need an observation window and a rollback path for new versions.