Threat · curated 20 Sep 2026
LiteLLM Supply Chain Attack — Free Exposure Check
First reported whiteintel.io
Coverage timeline
Single-source incident — first reported, latest, and curated coincide.
Why it matters
LiteLLM commonly sits in front of production AI infrastructure, so trojanized packages harvested exactly the credentials — cloud keys and Kubernetes tokens — that can unlock an entire environment, making this a high-impact AI supply-chain compromise defenders must check for.
Whiteintel describes a supply-chain attack in which two trojanized versions of the open-source LLM gateway LiteLLM (1.82.7 and 1.82.8) were published to PyPI on March 24, 2026, running attacker-controlled code that exfiltrated model-provider API keys, cloud access keys, SSH keys, and Kubernetes service-account tokens from affected environments. The page itself is a free hosted exposure-check that searches Whiteintel's index of leaked secrets by domain.
Summary
According to a single Whiteintel promotional page, two trojanized releases of the open-source LLM gateway LiteLLM — versions 1.82.7 and 1.82.8 — were published to the Python Package Index (PyPI) on March 24, 2026, and executed attacker-controlled code that exfiltrated secrets from host environments.[0]
Because LiteLLM commonly sits in front of production AI infrastructure, the malicious packages reportedly had access to high-value credentials — model-provider API keys, AWS/GCP/Azure cloud keys, SSH private keys, and Kubernetes service-account tokens — giving the incident an outsized blast radius from even a brief window of availability.[0]
All details derive from a single vendor page whose primary purpose is to promote Whiteintel's free 'exposure check' tool and paid disclosure/monitoring services; no independent corroboration, named threat actor, or technical indicators beyond the package version strings are provided, so the underlying incident claims should be treated as unverified.[0]
Attack chain
- Delivery — malicious package publication: Attackers published two trojanized LiteLLM releases (1.82.7 and 1.82.8) to PyPI on March 24, 2026; the malicious releases were live only briefly.[0]
- Execution — installation and deployment: Anyone who installed, built, or deployed the affected versions ran attacker-controlled code within their environment.[0]
- Collection and exfiltration — credential harvesting: The attacker code harvested and exfiltrated secrets present in the host environment, including model-provider API keys, cloud access keys and secrets, SSH private keys, and Kubernetes service-account tokens.[0]
Disclosure timeline
| Date | Event |
|---|---|
| March 24, 2026 | Trojanized LiteLLM 1.82.7 and 1.82.8 packages published to PyPI, per the Whiteintel page.[0] |
| August 21, 2026 | Whiteintel exposure-check page last updated.[0] |
How it works
The compromise is a supply-chain attack rather than exploitation of a code flaw: the published LiteLLM packages contained attacker-controlled code that ran at install/deploy time and read secrets from the host environment. Because LiteLLM typically fronts production AI infrastructure, the running code had access to model-provider API keys, cloud credentials, SSH keys, and Kubernetes tokens, which were then exfiltrated.[0]
Affected versions and patch status
| Product | Affected | Patch status |
|---|---|---|
| LiteLLM (PyPI package) | 1.82.7 and 1.82.8 | Guidance is to remove 1.82.7/1.82.8 and pin to a known-good or patched release predating the attack; no specific fixed version identified in the evidence.[0] |
Indicators of Compromise
| Type | Indicator | Context |
|---|---|---|
| other | litellm 1.82.7 (PyPI) | Trojanized LiteLLM release published to PyPI on March 24, 2026 that exfiltrated secrets; defenders should hunt for this version in build/deploy environments.[0] |
| other | litellm 1.82.8 (PyPI) | Second trojanized LiteLLM release published to PyPI on March 24, 2026 with the same credential-harvesting behavior.[0] |
Key takeaways
- A brief supply-chain compromise of a widely deployed AI gateway can yield outsized impact, since a single leaked cloud key or Kubernetes token can unlock an entire environment.[0]
- Because the only source is a vendor page promoting its own paid exposure-disclosure service, defenders should independently verify the incident and treat the marketed 'exposure check' results as estimated and unverified.[0]
Defensive actions
- Remove LiteLLM 1.82.7/1.82.8 and pin to a trusted release.: These specific versions contained attacker-controlled code; pinning to a known-good version prevents re-execution.[0]
- Rotate, revoke, and reissue all secrets present where an affected version ran.: Any API key, cloud access key, SSH key, or Kubernetes token in the affected environment should be assumed compromised and exfiltrated.[0]
- Invalidate active sessions and audit cloud, provider, and cluster logs for unauthorized access after March 24, 2026.: Detecting misuse of leaked credentials requires reviewing access logs from the exposure window onward.[0]