Summary
- CloudSEK estimates the earlier LiteLLM incident potentially exposed more than 2,500 organisations and 434,000 CI/CD pipelines.
- The compromise propagated from a malicious Trivy component into LiteLLM’s automated build and release process.
- The figures describe reconstructed exposure and do not prove that every named organisation or credential was compromised.
CloudSEK estimates that more than 2,500 organisations and 434,000 CI/CD pipelines were potentially exposed through the LiteLLM supply chain compromise, extending the estimated reach of an incident that propagated through trusted build automation.
CloudSEK reconstructed the exposure created by the compromise, which began upstream with the earlier attack on Aqua Security’s Trivy open-source vulnerability scanner. The researchers say LiteLLM itself was not directly targeted: its build pipeline automatically installed the compromised Trivy version, allowing the attack to propagate into subsequent LiteLLM releases.
Two affected LiteLLM versions, 1.82.7 and 1.82.8, were subsequently published through the Python Package Index. Malicious code embedded in those versions was designed to execute whenever Python ran on systems where the package had been installed, rather than depending on an application explicitly importing the malicious component.
The packages were available for only around 40 minutes, but automated dependency resolution and build processes enabled them to move quickly through development environments. CloudSEK estimates that the resulting exposure reached approximately 434,000 CI/CD pipelines and more than 2,500 organisations.
CloudSEK’s reconstructed dataset includes major European organisations such as Siemens, London Stock Exchange Group, Volkswagen, Munich Re, and Robert Bosch. The dataset records potential exposure paths and does not establish that each named organisation executed the malicious package, lost credentials, or suffered a confirmed compromise.
CloudSEK explicitly distinguishes exposure from compromise. A high-confidence organisation match reflects the strength of the link in its dataset, not proof that malicious code executed successfully or that attackers subsequently used any credentials. Individual impact would need to be established through each organisation’s own incident investigation.
The distinction is particularly important in software supply chain incidents, where the number of systems that retrieved or could have interacted with a malicious package can be substantially higher than the number where attackers obtained usable access. Exposure describes the possible blast radius; incident investigation determines how much of that radius became an actual compromise.
LiteLLM sits in an increasingly sensitive part of enterprise architecture. The open-source project acts as a Python library and proxy layer for interacting with multiple large-language-model providers, putting it close to API credentials, cloud services, development pipelines, application secrets, and AI-provider keys.
CloudSEK said potentially exposed information included package-publishing credentials, cloud keys, SSH keys, access tokens, environment variables, runtime data, and AI-provider credentials. Compromise of those assets can extend well beyond the original dependency, particularly where the same secrets grant access to source repositories, cloud infrastructure, Kubernetes environments, or automated deployment systems.
The propagation path also shows how several individually routine automation decisions can combine into a much larger dependency chain. A build system automatically retrieving an upstream tool is efficient; publishing an artefact automatically is efficient; downstream environments automatically consuming that artefact is efficient. Once a compromised component enters the sequence, the same automation can distribute the problem faster than human change controls can react.
AI infrastructure increases the concentration of that risk because model gateways and orchestration tools frequently connect to several services simultaneously. They may handle credentials for different model providers, retrieve enterprise data, integrate with applications, and execute inside development or production environments. A compromised control point can therefore provide access to systems far removed from the original software package.
The new analysis does not describe a new attack this week. It expands the estimated reach of a previously disclosed incident and provides a clearer picture of how far the malicious release may have travelled. The figure of 2,500 organisations should remain an exposure estimate unless individual organisations confirm compromise, but the underlying chain demonstrates how an upstream credential failure can move through multiple trusted projects before reaching enterprise environments.
