Malicious LiteLLM PyPI Releases Tied to Trivy Hack May Have Exposed 2,500+ Organizations

Two malicious releases of the popular LiteLLM package sat on PyPI for about 40 minutes in March 2026 carrying credential-stealing code that harvested cloud keys, SSH keys, Kubernetes tokens, and database passwords from any system that installed them. Threat-intelligence firm CloudSEK now says a dataset built from roughly 434,000 files the attackers captured maps potential exposure to more than 2,500 organizations, including named enterprises. That figure is captured attacker loot, not a confirmed victim count, but if your pipeline pulled LiteLLM 1.82.7 or 1.82.8 on March 24, treat every secret in that environment as compromised. The campaign traces back through a compromised CI chain rather than a single bug.

The mechanics are a lesson in how supply-chain attacks now cascade. The intrusion pivoted from an upstream compromise in the Trivy build chain into a build runner, then to an exfiltrated PyPI publishing token, and finally into poisoned public releases that end users installed. Forty minutes of availability was enough because so much of the modern pipeline is automated: unpinned installs like pip install litellm, floating dependency ranges, and auto-merged dependency bumps ingest a backdoored release into live builds the moment it appears. The window was small; the reach was not.

CloudSEK's dataset is unusual and worth understanding precisely. It was assembled from the attackers' own captured files and logs, obtained through confidential intelligence sources, not gathered from the organizations it names. The firm published a public lookup, searchable by name or domain, where each row shows an organization, a count of exposed secrets, a run count, and a High or Medium confidence label. A high-confidence match keys on identity signals in the captured CI runner environment, chiefly host identity and legitimate committer domains, and requires the organization's own domain to appear; repository namespaces alone earn only medium confidence. In plain terms, it is a heuristic correlation, so a high-confidence row indicates, by those identity signals, whose system a stolen file most likely came from, not a forensic certainty.

Am I affected, and what should I do first?

Do not wait for a lookup tool to confirm it. Search your internal artifact-proxy and build logs for any environment that resolved litellm==1.82.7 or 1.82.8 around March 24, 2026. If any builder, container, or developer machine touched those versions, assume the secrets exposed in that shell are compromised and rotate them immediately: cloud keys, SSH keys, Kubernetes tokens, database credentials, and any token the CI runner could read. Rotation first, forensics second.

How do you stop the next 40-minute window from mattering?

Remove the automation that turns a brief poisoning into an instant compromise. Pin dependencies with hashes (requirements.txt --require-hashes, poetry.lock) so an unexpected release cannot be pulled silently, and route installs through a private mirror or artifact proxy rather than straight from public PyPI. Strip long-lived cloud keys out of CI runners in favor of short-lived OIDC workload identity, so a stolen credential expires before it is useful, and block direct network egress from build steps.

Our read

This is a supervised-adversary-simulation problem before it is an incident-response one. The organizations best positioned right now are the ones that can answer, quickly and with evidence, a simple question: what did our build pipelines actually install, and what could those runners reach? The durable defense is to treat your own supply chain the way an attacker would, tracing what a poisoned dependency could touch, then constraining it with pinned hashes, private mirrors, and ephemeral credentials, and verifying those controls continuously rather than trusting that a package from a trusted project is trustworthy today. A dependency you did not pin is a decision you let someone else make.

Reporting by The Hacker News, citing CloudSEK; exposure figures are CloudSEK's assessment of captured attacker data. Sources linked above.

Related: GhostSplice: malicious MCP servers exfiltrate agent secrets · Gemini CLI CVE-2026-12537 and Claude Code CI flaws