Summary
- More than 95% of analysed organisation records appeared in collected data before the malicious LiteLLM packages were published.
- LiteLLM says its compromised PyPI releases originated from a Trivy dependency used in its CI/CD security workflow.
- The revised timeline shifts most of the observed exposure upstream within a multi-stage open-source supply chain compromise.
New analysis of the supply chain incident involving Trivy and LiteLLM has changed the attribution of a widely reported 2,500-organisation exposure estimate, with more than 95% of analysed organisations appearing in collected data before the malicious LiteLLM packages were published.
The wider campaign began with compromise of Trivy, the open-source vulnerability scanner maintained by Aqua Security, before malicious activity propagated into downstream development and release workflows.
LiteLLM disclosed in March that versions 1.82.7 and 1.82.8 of its PyPI package were compromised and remained available for roughly 40 minutes on 24 March before PyPI quarantined them. The project said it believed the compromise originated from the Trivy dependency used in its CI/CD security scanning workflow.
Initial estimates published in August put potential exposure above 2,500 organisations and roughly 434,000 CI/CD files. Those figures represented reconstructed exposure rather than a confirmed count of successfully compromised organisations.
SOCRadar has since carried out row-level analysis of 2,188 organisation records and found that 2,085 — more than 95% — showed data collection before the malicious LiteLLM packages were published on 24 March. Its timeline places collection activity several days earlier, shortly after malicious Trivy artefacts appeared.
LiteLLM remains part of the incident. Its malicious packages were real, could harvest credentials, and were distributed through a trusted software repository. The larger dataset, however, cannot be attributed primarily to a 40-minute LiteLLM publication window when most of the observed collection activity had already occurred.
Modern development environments combine open-source packages, GitHub Actions, container images, security scanners, build systems, package registries, and automation credentials. Once an attacker compromises one trusted component, malicious activity can spread across downstream systems and leave several projects appearing independently responsible for the same broader intrusion chain.
Reconstructing blast radius therefore depends on timestamps, package provenance, build records, version histories, and the sequence in which credentials were accessed or reused. Domain lists and exposed-file counts can indicate potential reach but do not, by themselves, identify which component caused each exposure.
The role of Trivy also places security tooling itself inside the supply chain risk model. Vulnerability scanners often require broad visibility over repositories, images, build artefacts, secrets, and CI pipelines in order to do their work. Those permissions become valuable to an attacker if the scanner or its release process is compromised.
AI development environments add further dependency depth because frameworks and model gateways frequently draw on large open-source ecosystems. A developer does not necessarily need to select a compromised component directly; transitive dependencies and automated build systems can introduce it further down the chain.
LiteLLM’s incident disclosure records the compromised versions and its conclusion that Trivy was the upstream source. SOCRadar’s later analysis reconstructs when records entered the exposed dataset and separates the earlier Trivy activity from the subsequent LiteLLM package window.
The revised attribution does not reduce the overall supply chain exposure. It changes where most of that exposure appears to have originated, replacing a downstream explanation with a timeline that points back to the compromised security scanner.
