A Dataset From the March LiteLLM Compromise Now Names More Than 2,500 Exposed Organisations

Two poisoned versions of LiteLLM, an open-source gateway that routes application traffic to multiple model providers, reached PyPI on 24 March 2026. According to LiteLLM's own incident report,

LiteLLM versions 1.82.7 and 1.82.8 were both malicious, and they carried their payloads differently. In 1.82.7 the code sat inside the gateway's own proxy_server.py file. Version 1.82.8 carried that plus a second file, litellm_init.pth.

That second file is the one that matters operationally. Python runs any .pth file automatically when the interpreter starts, so the payload executed on any machine where the package was simply installed. Nobody had to import LiteLLM into their code, and nobody had to choose it. LiteLLM notes that an unpinned transitive dependency, pulled in by an agent framework or an orchestration tool, was enough.

The payload swept environment variables, SSH keys, AWS, GCP and Azure credentials, Kubernetes tokens and database passwords. It encrypted what it found and sent it to models.litellm.cloud, a domain with no connection to the project. LiteLLM has since brought in Mandiant, rebuilt its release path, and started signing its Docker images so that users can verify an image came from the project.

The FBI attributes the campaign to a criminal group it calls TeamPCP, in FLASH-20260702-01 published on 2 July. The advisory names Trivy, Checkmarx KICS, LiteLLM and the Telnyx Python SDK among the compromised tools, which places the two windows in this article inside something considerably larger.

LiteLLM was not the first link in the chain. Its own incident report points to the Trivy dependency used in its CI/CD security scanning workflow, and says the incident may be linked to the broader compromise of that scanner. Aqua Security's advisory explains what happened to Trivy. After an earlier breach disclosed on 1 March, Aqua rotated its credentials, but not simultaneously. Aqua says the attacker could have used a still-valid token during that window to steal the newly rotated secrets and retain access. On 19 March the attacker overwrote 76 of the 77 version tags on the trivy-action GitHub Action and all seven tags on setup-trivy, pointing them at credential-stealing code.

What the numbers actually say

CloudSEK's figures are 2,500 or more organisations and 434,000 CI/CD pipelines. Read the second one carefully. CloudSEK told The Hacker News that the 434,000 counts captured files and exfiltration events rather than distinct pipelines, runs or jobs. It described one captured file as roughly one job execution, while saying it does not present the total as unique jobs without independent deduplication. That is a useful approximation and a different claim from the one the headline makes.

The organisation list carries its own qualifier, which CloudSEK states in its methodology: a high-confidence match describes the strength of the exposure match, not proof of compromise or attacker use. The attribution runs on captured material and log files obtained through intelligence sources, not on data gathered from the organisations named. Well known manufacturers, financial institutions, technology vendors and healthcare and life sciences companies appear in the published table. None of that establishes that any credential was used.

Why this reaches device manufacturers

A release runner in a medical device manufacturer's pipeline holds the same class of secret LiteLLM lost, and one more besides: the credentials that request a signature and publish the resulting build. The failure here was never in the shipped artifact. It was in the machine that produced it, and it moved from a security scanner into a build system into a public package registry.

That is the gap an SBOM does not close. Section 524B(b)(3) of the US FD&C Act requires a software bill of materials covering commercial, open-source and off-the-shelf components in the device, and FDA's premarket cybersecurity guidance sets out what a credible package looks like. An SBOM describes what ships. It says nothing about what was installed on the runner that produced the build, which is where this payload ran. Section 524B(b)(1) requires a plan to monitor, identify and address postmarket cybersecurity vulnerabilities and exploits. Whether a build produced during that window can still be trusted is a question that has to be answered somewhere in that plan, with a record of how it was answered.

European timing sharpens it. Article 13(5) of the Cyber Resilience Act requires manufacturers to exercise due diligence when integrating third-party components, including free and open-source software. Article 13(6) requires them to report a vulnerability found in an integrated component back to whoever maintains it, and to remediate it under the vulnerability handling requirements in Annex I Part II. Those obligations bind from 11 December 2027. The reporting duty under Article 14 arrives first, on 11 September 2026 under Article 71(2), and Article 69(3) applies it to products already on the EU market. Separately, NIS2 lists medical device and in vitro diagnostic manufacturers in Annex II as important entities. Article 21(2)(d) puts supply chain security among the ten minimum risk-management measures, and Article 21(3) requires entities to take into account the vulnerabilities specific to each direct supplier and the overall quality of that supplier's cybersecurity practices, including the security of their development procedures. A supplier whose build system was compromised is the relationship those provisions are about.

What MedTech teams should check

The five items below run roughly in order. Scoping comes first because everything after it depends on knowing which hosts and which builds fall inside the affected windows. Items three and five are the ones that will outlive this incident, since they change what you document and what you ask of suppliers.

1. Scope both windows precisely. For LiteLLM, 24 March 2026, 10:39 to 16:00 UTC. For Trivy, per Aqua's advisory, 19 March 18:22 to about 21:42 UTC for the v0.69.4 binary and image, 19 March about 17:43 to 20 March about 05:40 UTC for trivy-action, and 22 March 15:43 to 23 March about 01:40 UTC for the Docker Hub 0.69.5 and 0.69.6 images. LiteLLM publishes community-contributed scripts for scanning GitHub Actions and GitLab CI job logs. Extend the search to cached wheels, container base images and developer laptops, not only to teams who knowingly use either tool.

2. Rotate publishing tokens and signing credentials before cloud keys. Those are the ones that reach shipped product. LiteLLM's guidance is to treat every credential present on an affected system as compromised.

3. Determine whether any regulated device software release was built on an affected host inside either window, and document the assessment. Under Section 524B(b)(1) this belongs in the postmarket plan with a record, not in an IT ticket.

4. Hunt for the fallback exfiltration artifact. Aqua's advisory notes the malware created a public repository on the victim's own GitHub account with a tpcp-docs- prefix and uploaded stolen data as a release asset tagged data-<timestamp>. Search by prefix, since an exact-name search for tpcp-docs will miss them.

5. Rewrite the supplier question. Not "were you affected by LiteLLM" but "did any build that produced software you shipped to us run on a host that installed LiteLLM 1.82.7 or 1.82.8 on 24 March, or Trivy v0.69.4 on 19 March". Suppliers can answer the second question.

The question that remains

The FBI warned on 2 July, in FLASH-20260702-01, that actors in this campaign are likely to use harvested credentials well after the original intrusion. A rotation done in April against an incomplete inventory did not close this. What manufacturers need to establish is not whether they were exposed, but whether anything already on the market was built on a machine they can no longer vouch for.

Key sources

1. LiteLLM, Security Update: Suspected Supply Chain Incident, 24 March 2026

2. Aqua Security, GHSA-69fq-xp46-6x23 (CVE-2026-33634), published via the GitHub Advisory Database

3. CISA, Adds One Known Exploited Vulnerability to Catalog, 26 March 2026

4. FBI, Cyber Criminal Group TeamPCP, FLASH-20260702-01, 2 July 2026

5. CloudSEK, 2,500+ Companies and 434,000 CI/CD Pipelines Exposed, 11 August 2026