Over 2,500 Organizations Impacted by LiteLLM Supply Chain Attack

1. Executive summary

A supply chain attack on the open-source LiteLLM Python library and proxy server — traced to a prior compromise of the Trivy vulnerability scanner — resulted in two malicious package versions (1.82.7 and 1.82.8) being published to PyPI in March 2026. The packages contained credential-stealing code that executed on every Python invocation without explicit import, harvesting cloud keys, SSH keys, Kubernetes tokens, database passwords, and other secrets from affected systems. Although the malicious packages were live for approximately 40 minutes, CloudSEK reports that over 2,500 organizations and 434,000 CI/CD pipelines were potentially exposed. EMEA financial services entities that consumed LiteLLM in build pipelines or production environments should treat all secrets accessible to the library as compromised and rotate immediately. No verified reference data (CVSS, CISA-KEV) was resolved for this item; attribution to the actor "TeamPCP" is single-sourced and unconfirmed.

2. Regulatory framing

Article	Trigger (the fact in this item)	Practical impact
DORA Art. 28: ICT third-party risk — general principles	The compromise propagated through a third-party OSS dependency (Trivy) into the organisation's own CI/CD pipeline via an automated build tool, demonstrating cascading third-party ICT risk.	Clients must assess whether LiteLLM or Trivy are present in their ICT supply chain and account for this transitive risk in their third-party risk register.
DORA Art. 19: reporting of major ICT-related incidents to competent authorities	If a client's CI/CD pipelines installed the malicious LiteLLM versions, secrets accessible to the library (cloud keys, tokens, SSH keys) may have been exfiltrated, potentially constituting a major ICT-related incident.	Clients that confirm exposure must classify the incident per DORA Art. 18 and determine whether major-incident reporting thresholds are met.
NIS2 Art. 21(2)(d): supply chain security measures	The attack chain exploited an OSS dependency three layers deep (Trivy → LiteLLM build system → LiteLLM release), directly implicating supply chain security controls.	In-scope NIS2 entities must review whether their supply chain security measures account for transitive OSS dependency compromise in CI/CD pipelines.

3. Technical analysis & attack chain

Attack chain (confirmed steps from source reporting)

Initial compromise — Trivy: The threat actor compromised the Trivy open-source vulnerability scanner (maintained by Aqua Security). The mechanism of the initial Trivy compromise is not detailed in the available sources.
Transitive compromise — LiteLLM CI pipeline: LiteLLM's CI pipeline automatically installed the compromised Trivy version. The actor did not target LiteLLM directly; the compromise was a downstream consequence.
Credential abuse — build system access: A single unrevoked token allowed the attacker to pivot from the compromised Trivy installation through the LiteLLM build system to the LiteLLM release pipeline. CloudSEK describes this as "one unrevoked token, three tools deep."
Malicious package publication: Two malicious LiteLLM versions — 1.82.7 and 1.82.8 — were pushed to PyPI. The packages were live for approximately 40 minutes.
Payload execution on victim systems: The malicious code executed on every Python invocation with no explicit import required. The payload ran on all systems where the package was installed — including developer laptops, ephemeral CI runners, and cached container layers.
Secret harvesting: The payload captured secrets accessible to the LiteLLM library, including: package publishing credentials, cloud keys, SSH keys, Kubernetes tokens, database passwords, environment variables, runtime data, AI provider keys, and secrets retrievable through instance metadata services (IMDS).
Dataset construction: CloudSEK obtained a dataset built from approximately 434,000 files the attackers captured, mapping potential exposure to over 2,500 organizations and 434,000 CI/CD pipelines.

Technical specifics

Affected packages: litellm versions 1.82.7 and 1.82.8 on PyPI.
Execution mechanism: Malicious code triggered on every Python invocation — no explicit import litellm required. This means any environment with the package installed was affected, including dependency resolution contexts.
Propagation speed: Automated build systems, scheduled jobs, dependency resolvers, ephemeral runners, and cached container layers all contributed to rapid propagation within the 40-minute window.
Secrets at risk: Any secret accessible to the LiteLLM library — present in process memory, injected into the CI/CD job, stored on disk, or retrievable through IMDS — should be considered compromised.

Attribution caveat: The threat actor is identified as "TeamPCP" by CloudSEK. No MITRE ATT&CK profile or independent corroboration is available in the verified reference data. This attribution is single-sourced; verify before enforcement.

Exposure scope caveat: CloudSEK explicitly states the 2,500+ organization and 434,000 pipeline figures describe "reconstructed exposure" — not proof that every listed organization was successfully compromised or that every credential was stolen. Compromise should be independently verified per organisation. Named potentially-affected organisations include London Stock Exchange Group, Deutsche Bahn, Siemens, Volkswagen, Orange, and others.

4. Mitigation & containment

P1 — Within 24 hours

Determine whether litellm versions 1.82.7 or 1.82.8 were installed in any environment (production, staging, development, CI/CD runners, developer workstations, container images). Check PyPI download logs, pip audit trails, requirements.txt lockfiles, Poetry/PDM locks, and container layer caches.
If exposure is confirmed: isolate affected systems immediately. Treat all secrets accessible to the LiteLLM library as compromised — including cloud provider credentials (AWS, GCP, Azure), SSH keys, Kubernetes service account tokens, database passwords, environment variables, AI provider API keys, and package publishing credentials.
Begin rotation of all potentially compromised credentials, service accounts, and active sessions. Prioritise cloud root/admin keys, Kubernetes cluster-admin tokens, and any credentials with write access to source repositories or package registries.
Revoke and regenerate any package publishing credentials (PyPI, npm, etc.) that were present in affected environments.

P2 — Within 72 hours

Review CI/CD logs, build artefact logs, and cloud audit trails to determine the exposure scope and timeframe. Look for anomalous outbound connections or data exfiltration from systems that ran the malicious versions.
Pin LiteLLM to a known-clean version (pre-1.82.7) or upgrade to a version published after the malicious releases were removed and the build pipeline was sanitised. Verify package hashes against PyPI records.
Clear all cached container layers and CI runner caches that may retain the malicious package version.
Audit the Trivy version used in CI pipelines — ensure it is not the compromised version from the Aqua Security breach.

P3 — Within 7 days

Implement dependency pinning with hash verification (e.g., pip install --require-hashes) for critical dependencies like LiteLLM in all build pipelines.
Review CI/CD pipeline design to prevent transitive compromise: restrict token scopes, implement short-lived credentials, and ensure build tools (like Trivy) cannot inject malicious code into build artefacts through unrevoked tokens.
Conduct a retrospective review of all secrets that transited any system where the malicious LiteLLM versions were installed, including those retrieved via IMDS.
Assess whether the incident meets DORA Art. 18 classification thresholds and Art. 19 reporting obligations.

5. Indicators of compromise

No atomic indicators of compromise (IPs, domains, hashes, file paths) are available in the source material. The sources describe package versions and behaviours but no network indicators, file hashes, or command-line artefacts.

Behavioural indicators

Behaviour	Where to observe	Confidence
Installation of `litellm` version 1.82.7 or 1.82.8 from PyPI	PyPI download logs, pip install logs, CI/CD build logs, container build logs	High — confirmed in source
Python process executing credential-harvesting code without explicit `import litellm`	Process monitoring, EDR telemetry on systems with the package installed	High — confirmed in source
Outbound network connections from CI/CD runners or build containers to attacker-controlled infrastructure exfiltrating harvested secrets	Network firewall logs, egress proxy logs, cloud flow logs	Medium — inferred from described payload behaviour; no specific C2 indicators provided
Access to instance metadata service (IMDS) from processes running the malicious LiteLLM package	Cloud provider metadata service access logs, EDR process-network correlation	Medium — confirmed capability in source; no specific IOCs

6. Detection

Insufficient indicators to author detection rules. The sources do not provide file hashes, distinctive strings, command-line arguments, mutex names, registry keys, or network indicators that could be used to construct YARA or Sigma rules. Detection should rely on the behavioural indicators in §5 — specifically, identifying systems where litellm versions 1.82.7 or 1.82.8 were installed and reviewing for anomalous secret access or outbound data transfers.

7. Sources

SecurityWeek — "Over 2,500 Organizations Impacted by LiteLLM Supply Chain Attack" — https://www.securityweek.com/over-2500-organizations-impacted-by-litellm-supply-chain-attack/ — 2026-08-12
The Hacker News — "Malicious LiteLLM Releases Tied to Trivy Hack May Have Exposed 2,100+ Organizations" — https://thehackernews.com/2026/08/malicious-litellm-releases-tied-to.html — 2026-08-12
CloudSEK (referenced via SecurityWeek and The Hacker News reporting)

8. Adverse Trace position

This is a high-severity supply chain compromise with broad potential impact across EMEA financial services. The attack chain — Trivy compromise → LiteLLM CI pipeline → malicious PyPI release — demonstrates how a single unrevoked token three tools deep can produce ecosystem-wide exposure. The 40-minute package availability window was sufficient for automated build systems to propagate the malicious code to over 434,000 CI/CD pipelines. Clients that consumed LiteLLM versions 1.82.7 or 1.82.8 in any capacity must treat all secrets accessible to the library as compromised and rotate immediately. Attribution to "TeamPCP" is single-sourced from CloudSEK and unconfirmed — we will not treat it as established until independently corroborated. No CISA-KEV entry or CVSS score exists for this item. We are monitoring for release of atomic IOCs (C2 domains, IPs, file hashes) from CloudSEK's full report and will issue an update if they become available. Clients should prioritise dependency auditing and credential rotation over threat-hunting for specific indicators at this time.

Read the original source →

Published via PulseTrace — Adverse Trace threat intelligence.