LiteLLM Supply-Chain Hack Maps Secret Exposure Across 2,500 Organisations

A malicious LiteLLM package incident now carries a larger enterprise-exposure map after CloudSEK tied the March supply-chain attack to roughly 434,000 captured files, The Hacker News reported.

The dataset changes the incident from a short-lived package compromise into a credential-audit problem for AI and developer-tooling teams.

CloudSEK's public lookup lists potential exposure for more than 2,500 organisations and labels matches by confidence, but those entries do not establish confirmed compromise at every named company.

Build systems that held durable tokens during the install window still need local verification even after the package versions disappeared from the public index.

The exposed material came from attacker-captured loot and logs rather than direct collection from the organisations themselves.

High-confidence matches depend on identity signals in CI runner environments, including host identity and legitimate committer domains, while repository namespace matches support only medium-confidence claims.

LiteLLM's March incident note identified 1.82.7 and 1.82.8 as the compromised releases.

The packages were live on PyPI on March 24 for about 40 minutes from 10:39 UTC, while the project set a broader suspect-installation window through 16:00 UTC.

That wider window covers delayed builds and dependency pulls around the package removal.

The technical risk extends beyond direct LiteLLM users.

Version 1.82.8 included a litellm_init.pth startup file, meaning Python could process the malicious hook when a Python process started in that environment even if the application did not import LiteLLM.

The malicious code swept across host configuration data, developer access material, cloud secrets, Kubernetes access tokens and database login values.

Stolen material was encrypted and sent to models.litellm[.]cloud, a lookalike destination that was not part of the LiteLLM project.

Unit 42's analysis recorded the payload reading model API keys, including OPENAIAPIKEY and ANTHROPICAPIKEY.

The incident sits inside the wider TeamPCP campaign tied to Aqua Security's Trivy scanner.

Aqua's advisory put the March 19 activity after incomplete credential rotation and described malicious commits to Trivy-related GitHub Action tags plus a malicious Trivy 0.69.4 release.

CVE-2026-33634 now covers the ecosystem compromise.

The Hacker News confirmed that the CVE record listed BerriAI LiteLLM 1.82.7 through 1.82.8 alongside the Trivy components, and CISA added the vulnerability to its Known Exploited Vulnerabilities catalogue on March 26.

The agency listing makes the incident a deadline-driven remediation item for U.S. federal systems and a high-priority reference point for private security teams.

Published accounts diverged on how the LiteLLM releases reached PyPI.

CloudSEK linked the releases to the poisoned build, LiteLLM pointed to a direct PyPI upload outside its official CI/CD workflow, and Unit 42 placed PyPI publishing-token theft after the Trivy breach.

CloudSEK treated those accounts as sequential rather than conflicting.

In that reading, one part of the record concerns acquisition of the publishing credential, and the other part concerns the later upload path.

The confirmed downstream effects remain narrower than the exposure map.

Checkmarx connected stolen credentials from the Trivy attack to unauthorised GitHub access and malicious artifact publication, and Mercor said it was affected by malicious LiteLLM versions.

CERT-EU separately put the European Commission AWS incident in the high-confidence category and gave the data-loss estimate as about 91.7 GB of compressed material.

The remediation work is therefore broader than uninstalling a bad package.

The FBI advisory directs organisations to look for LiteLLM 1.82.7 or 1.82.8 during the March 24 audit window, rotate secrets reachable from those hosts and check GitHub organisations for TeamPCP repository indicators.

Aqua's advisory also warned that exact-name searches could miss data stores created with a tpcp-docs prefix and timestamped release assets.

The operational burden falls on build, platform and AI application owners together.

A poisoned dependency in an agent framework or orchestration tool could land in a runner without a team consciously choosing LiteLLM, so package inventories alone may miss hosts that briefly executed the startup hook.

Secret rotation needs to cover what those runners could read, not only credentials visibly tied to LiteLLM.

CloudSEK did not detail pre-publication outreach to named organisations or say whether any disputed inclusion.

That leaves the practical test at the host and repository level: verify local LiteLLM installations, rotate reachable secrets and search GitHub organisations for TeamPCP indicators.