One unrevoked token, three tools deep: how to read CloudSEK's 2,500-org LiteLLM list

CloudSEK has published a searchable lookup built from roughly 434,000 files it assessed as captured by the TeamPCP campaign, mapping potential exposure to more than 2,500 organizations after two malicious LiteLLM releases sat on PyPI for about 40 minutes in March ^[1][2]. The reason to care is the plumbing rather than the headcount: according to CloudSEK, TeamPCP never targeted LiteLLM at all, and the project's build was poisoned because its CI pipeline automatically installed the compromised Trivy release ^[3][4].

CloudSEK's own summary of the chain is the useful sentence: "Trivy, then the [LiteLLM] build system, then the LiteLLM release: one unrevoked token, three tools deep" ^[5]. Upstream, Aqua Security said attackers retained access after an incomplete credential rotation and on March 19 force-pushed malicious commits to 76 of 77 trivy-action version tags and all seven setup-trivy tags while publishing a malicious Trivy 0.69.4 ^[6]. That is every trivy-action tag but one ^[7]. Google tracks the actor as UNC6780 ^[8]. The ecosystem compromise is CVE-2026-33634, added to CISA's Known Exploited Vulnerabilities catalog on March 26, and The Hacker News confirmed on August 12 that the CVE record now lists BerriAI LiteLLM 1.82.7 through 1.82.8 alongside the Trivy components ^[9][10].

The execution mechanism is why "we do not use LiteLLM" is not an answer. Version 1.82.8 shipped a file named litellm_init.pth, which Python processes at interpreter startup, so the payload ran whenever any Python process started in that environment, imported or not ^[11]. It collected environment variables, SSH keys, cloud credentials, Kubernetes tokens, and database passwords, then encrypted and sent them to models.litellm[.]cloud, a domain unrelated to the project ^[12]. Unit 42 records the payload reading model API keys including OPENAI_API_KEY and ANTHROPIC_API_KEY ^[13]. LiteLLM's advisory notes an unpinned transitive dependency, including one pulled in by an agent framework or orchestration tool, could have delivered it without anyone choosing it ^[14].

Read the labels for what they claim. A High rating asserts whose systems a file came from, keyed on identity signals in the captured CI runner environment, chiefly host identity and legitimate committer domains, with the organization's own domain required to appear ^[15]. Repository namespaces support only Medium ^[16]. NVIDIA, Cisco, Deloitte, Volkswagen, FedEx, Siemens and X Corp are among the entries, and CloudSEK says the figures describe reconstructed exposure, not proof that every listed organization was compromised ^[17][18][19]. The dataset came from confidential intelligence sources and consists of loot and logs taken from the campaign, not data collected from the named parties ^[20]. Both CloudSEK and LiteLLM tell affected teams to rotate rather than wait for proof ^[21].

Scope rotation by time and reach, not by package. The compromised versions were live from 10:39 UTC on March 24, but LiteLLM tells users to treat any install that day up to 16:00 UTC as suspect, roughly eight times the live window ^[22][23]. CloudSEK's guidance is to treat any secret accessible to the library as compromised, including secrets in process memory, injected into the job, on disk, or retrievable through an instance metadata service, then validate, rotate service accounts and sessions, and review logs ^[24][25]. The FBI's July 2 advisory FLASH-20260702-01 warns affiliated actors are likely to weaponize exfiltrated credentials long after the initial compromise, and tells organizations to rotate CI/CD secrets, publishing tokens, and cloud credentials from the exposure windows ^[26].

Watch three things. Neither malicious version appears in the package's release history as of August 12, while 1.82.6 and 1.83.0 remain available ^[27]. How the malicious releases reached PyPI is disputed across the published accounts, which matters for anyone reconstructing their own timeline ^[28]. And CloudSEK expects the next major supply-chain attack to target AI infrastructure, on the argument that compromising an AI control point exposes the identities and systems around it ^[29].