CloudSEK says its reconstructed dataset covers more than 2,500 organizations and roughly 434,000 potentially exposed CI/CD pipelines. Those figures are useful for understanding the possible scale of the campaign, but they do not establish that each organization downloaded the bad package, executed it, had credentials stolen, or suffered follow-on access. CloudSEK explicitly says its “high-confidence” organization matches should trigger private validation and investigation rather than public claims of compromise.
The underlying package compromise is well established. The Python Packaging Authority’s PYSEC-2026-2 advisory identifies LiteLLM 1.82.7 and 1.82.8 as affected releases containing automatically activated credential-harvesting malware. Independent technical analysis from Datadog Security Labs traced the releases to the wider TeamPCP supply-chain campaign that began with a compromise of Aqua Security’s Trivy tooling.
For IT teams, the action is straightforward but broader than uninstalling a Python package: identify every workstation, build agent, container image, virtual environment, and CI runner that could have installed either LiteLLM release; preserve evidence; then rotate credentials that were available to those processes.
The company list is an exposure lead, not a victim list
CloudSEK’s August report names AWS, Samsung Electronics, Salesforce, Cisco, Siemens, Volkswagen, FedEx, Zscaler, and other major organizations in its exposure dataset. It reports counts of observed “secrets” and “runs” for selected entities, but it does not publicly provide the underlying logs, affected repositories, dates of execution, or evidence that an attacker used a particular company’s credentials.
That limitation does not make the report irrelevant. It defines a potential notification and threat-hunting population at a scale few organizations could reconstruct on their own. But it does mean readers should resist turning a list of matched domains and pipelines into an assertion that a named company was hacked.
CloudSEK is unusually direct about this in its own methodology. Its labels distinguish potentially exposed environments from probable compromise and confirmed compromise, and its public report says a confirmed incident requires evidence such as malicious execution, credential exfiltration, unauthorized access, or downstream use. None of those are publicly demonstrated for the named companies.
The key question for a security team is therefore narrower and more useful: did an affected environment install litellm==1.82.7 or litellm==1.82.8, and what secrets could that environment read at the time? An organization not named by CloudSEK could still have exposure; a named organization may have already rotated credentials and found no malicious execution. The dependency evidence matters more than the logo list.
Two malicious releases, with a major execution difference
The PyPA advisory confirms that both LiteLLM 1.82.7 and 1.82.8 contained malware designed to collect sensitive files and credentials, then send the data to attacker-controlled infrastructure. Its advisory says the code targeted SSH keys, Git and Docker credentials, .env files, Kubernetes service-account tokens, database and LDAP configuration, shell-history files, crypto-wallet keys, cloud metadata credentials, and AWS Secrets Manager data. It also describes a persistence mechanism masquerading as a “System Telemetry Service” and Kubernetes activity.
The difference between the two versions matters during incident response. Datadog Security Labs found that version 1.82.7 embedded its malicious payload in litellm/proxy/proxy_server.py, meaning the malicious path depended on using the relevant LiteLLM proxy code. Version 1.82.8 added litellm_init.pth, a Python startup hook that can execute code whenever Python starts after the package is installed.
That .pth file changes the usual assumption that a dependency becomes dangerous only after an application imports or calls it. A developer who installed version 1.82.8 into a virtual environment and later ran an unrelated Python command could have triggered the payload. For CI/CD, where pip, test runners, build scripts, linters, and deployment tooling often launch Python repeatedly, that is an especially bad design.
Windows administrators should not dismiss the incident because the publicly documented persistence behavior focuses on Linux user-level systemd and Kubernetes. The Python startup-hook mechanism is not inherently Linux-only. Windows developer workstations, GitHub Actions self-hosted runners, Azure DevOps agents, and Windows-based build images are all relevant if they installed the compromised package and started Python afterwards.
The Trivy compromise was the real initial foothold
LiteLLM was not breached through a flaw in its application code. Its maintainers said the incident originated with a compromised Trivy dependency used in the project’s CI/CD process. The attacker obtained the LiteLLM PyPI publishing token and used it to upload malicious releases directly to the real project on PyPI.
Aqua Security’s advisory documents the preceding Trivy compromise in concrete terms: on March 19, attackers used compromised credentials to publish malicious Trivy 0.69.4, force-push 76 of 77 version tags in aquasecurity/trivy-action, and replace all tags in aquasecurity/setup-trivy with malicious commits. The company lists the affected Trivy action versions and specifies that safe version or commit pinning would have avoided parts of the tag-rewrite attack.
This is the operational lesson that should concern Windows and enterprise administrators more than LiteLLM’s AI branding. A workflow reference such as a mutable GitHub Action tag is an executable dependency. If a security scanner, installer action, setup script, or package version is allowed to change behind a stable-looking reference, the security control itself becomes a delivery path for attacker code.
LiteLLM’s maintainers said they rotated maintainer accounts and removed the bad versions. They also said official proxy Docker image users were not affected because dependencies were pinned in requirements.txt. That is a useful but limited mitigation: it addresses a declared image path, not every developer-created image, cached wheel, local virtual environment, or CI runner that resolved the malicious PyPI versions during the exposure window.
“Forty minutes” is not the whole timeline
CloudSEK describes the LiteLLM packages as live for approximately 40 minutes. That figure has been widely repeated because it illustrates the speed at which automated dependency systems can distribute a bad release. Yet other incident material places the public availability closer to several hours. A PyPI-hosted compromise-scanning project, citing package upload timing, says the releases were available for about three hours before PyPI quarantined them.
The difference should not be quietly erased. It may reflect different definitions: CloudSEK could be measuring the period in which the specific releases were actively reachable through its data source, while other analysis measures time until quarantine or removal. Neither window is short enough to treat exposure as implausible in an automated build environment.
A scheduled build fleet can resolve a new package across hundreds or thousands of runners without a person seeing a version change. Cached artifacts complicate matters further: the registry can remove a malicious wheel while a runner cache, internal artifact proxy, developer’s virtual environment, or container layer retains it. The time to investigate starts from the first possible installation, not the time the public package disappeared.
What affected teams should do now
The PyPA advisory recommends assuming credentials available to the LiteLLM environment may have been exposed, isolating the environment, and reviewing it for unexpected modifications and network traffic. That is the right baseline because malware that copied a token before removal cannot be remediated by deleting a package afterward.
A practical response should include the following steps:
- Search dependency manifests, lock files, build logs, package caches, virtual environments, and container build histories for LiteLLM 1.82.7 and 1.82.8.
- Treat every CI job and developer environment that installed version 1.82.8 as potentially executed, even if no application explicitly imported LiteLLM.
- Rotate cloud access keys, GitHub and GitLab tokens, package-registry credentials, SSH deploy keys, Kubernetes service-account tokens, database passwords, AI-provider API keys, and secrets injected into affected jobs.
- Review source-control, cloud, Kubernetes, package-registry, and identity-provider logs beginning with the March 2026 exposure period for anomalous token use, new service accounts, unfamiliar repository creation, unusual egress, and suspicious publishing activity.
- Rebuild affected runner images and development environments from known-clean sources rather than relying solely on an in-place package removal.
The release names are precise, the malware is confirmed, and the supply-chain path is documented. What remains unconfirmed is the claimed victim count at individual companies. That does not lower the urgency: it clarifies where it belongs—on proving exposure locally, rotating what an affected process could read, and removing mutable dependencies from the release path before the next 40-minute window becomes a months-long credential incident.
