LiteLLM PyPI Supply-Chain Attack: 2,100+ Organizations Exposed — Detection, Hunt Queries, and Credential Rotation Guide

In March 2026, two malicious releases of LiteLLM — one of the most widely deployed Python libraries for brokering calls to large language model APIs — were live on the Python Package Index (PyPI) for roughly 40 minutes before being pulled. That was long enough. The poisoned packages carried credential-harvesting code designed to sweep compromised systems for cloud access keys, SSH private keys, Kubernetes service-account tokens, database passwords, and virtually any other secret material within reach of the installing process.

Threat intelligence firm CloudSEK has now obtained and analyzed a dataset of approximately 434,000 files captured by the attackers. Their mapping of that dataset indicates potential exposure across more than 2,100 organizations. The campaign has been tied to the same intrusion that compromised Trivy, the popular open-source vulnerability scanner — a classic cascading supply-chain scenario in which one trusted project's compromise is leveraged to poison downstream dependencies that sit inside thousands of CI/CD pipelines and production AI workloads.

If your organization builds, deploys, or operates anything in the LLM/AI application stack — and in 2026, that is most organizations — you need to treat this as a confirmed credential-exposure event, not a theoretical supply-chain risk. The window was short, but LiteLLM's install base is enormous, and automated pipelines pulling "latest" during that 40-minute window would have ingested the malicious code without any human interaction at all.

Technical Analysis

Affected Component

• Package: litellm on PyPI
• Malicious releases: 1.82.7 and 1.82.8 (published and removed within ~40 minutes in March 2026)
• Safe baseline: Releases prior to the malicious window, and the subsequently re-published clean releases. Any environment that resolved litellm to one of the two poisoned versions during the exposure window must be considered compromised.
• Platforms: Any system that ran pip install litellm (or a dependency resolver that pulled it transitively) during the window — developer workstations, CI/CD runners, container builds, and production servers running LLM proxy/gateway workloads.

LiteLLM is particularly high-value as a target because it is architecturally designed to sit at the center of AI traffic: it stores provider API keys (OpenAI, Anthropic, Azure, Bedrock, Vertex), runs as a proxy holding credentials in environment variables and configuration files, and is frequently deployed with broad cloud IAM permissions. A stealer executing in that context inherits an exceptionally rich secrets environment.

How the Attack Works

From a defender's perspective, the attack chain is straightforward and consistent with recent PyPI poisoning tradecraft:

1. Delivery: The attackers gained the ability to publish to the legitimate litellm project — consistent with maintainer-credential compromise stemming from the Trivy supply-chain intrusion — and pushed two releases containing malicious code executed at install or import time.
2. Execution: When the package was installed or first imported, the payload ran with the privileges of the installing user or service account. In CI/CD contexts, that is often a build identity holding cloud deploy credentials.
3. Collection: The stealer enumerated high-value secret locations: ~/.aws/credentials, ~/.aws/config, ~/.ssh/ private keys, ~/.kube/config and in-cluster service-account tokens (/var/run/secrets/kubernetes.io/serviceaccount/token), .env files, shell history, and process environment variables — a common source of database passwords and API tokens.
4. Exfiltration: Collected material was staged and transmitted to attacker-controlled infrastructure. CloudSEK's dataset — roughly 434,000 harvested files — reflects the aggregate yield of that collection across victims.
5. Scope amplification: Because LiteLLM is commonly pulled as a transitive dependency and installed via unpinned requirements in automated builds, a 40-minute window is sufficient to reach thousands of build agents and freshly deployed containers.

Exploitation Status

This is confirmed, completed in-the-wild distribution — not a proof of concept. Malicious artifacts were served from the official PyPI index, executed on victim systems, and exfiltrated data at scale. The 2,100+ organization figure is derived from analysis of actual stolen data, which means affected organizations may not yet know they were hit. There is no CVE assigned to this event; it is a malicious-package incident, tracked via package version identifiers rather than a vulnerability identifier. Do not wait for a CVE or a KEV listing — those frameworks do not govern this incident class.

Detection & Response

The hunt has two phases: (1) determine whether the malicious versions were ever installed anywhere in your estate, and (2) if they were, pivot to credential-exposure scoping and exfiltration review. Version presence is a binary, high-confidence indicator — this is one of the rare hunts where a true positive is unambiguous.

---
title: Installation of Malicious LiteLLM PyPI Releases
id: 3f8a2b14-7c1d-4e59-9a02-6d4b8c1e5f70
status: experimental
description: Detects pip or pip3 installing the malicious LiteLLM versions (1.82.7 / 1.82.8) distributed via the PyPI supply-chain compromise tied to the Trivy intrusion. Any hit is a confirmed exposure event requiring credential rotation.
references:
  - https://thehackernews.com/2026/08/malicious-litellm-releases-tied-to.html
  - https://attack.mitre.org/techniques/T1195/001/
author: Security Arsenal
date: 2026/08/26
tags:
  - attack.initial_access
  - attack.t1195.001
logsource:
  category: process_creation
  product: linux
detection:
  selection_installer:
    Image|endswith:
      - '/pip'
      - '/pip3'
      - '/python'
      - '/python3'
      - '/uv'
      - '/poetry'
  selection_versions:
    CommandLine|contains:
      - 'litellm==1.82.7'
      - 'litellm==1.82.8'
      - 'litellm 1.82.7'
      - 'litellm 1.82.8'
  condition: all of selection_*
falsepositives:
  - None expected; these versions are confirmed malicious artifacts
level: critical
---
title: Python Process Accessing Credential and Secret Stores
id: 9c4e7d21-2a6b-4f83-b510-8e2c6a9d3b41
status: experimental
description: Detects Python or pip processes reading cloud credentials, SSH private keys, Kubernetes tokens, or dotenv files — consistent with the LiteLLM credential-stealer collection behavior post-install.
references:
  - https://thehackernews.com/2026/08/malicious-litellm-releases-tied-to.html
  - https://attack.mitre.org/techniques/T1552/001/
author: Security Arsenal
date: 2026/08/26
tags:
  - attack.credential_access
  - attack.t1552.001
  - attack.t1552.004
logsource:
  category: process_creation
  product: linux
detection:
  selection_interpreter:
    Image|endswith:
      - '/python'
      - '/python3'
      - '/pip'
      - '/pip3'
  selection_targets:
    CommandLine|contains:
      - '.aws/credentials'
      - '.aws/config'
      - '.ssh/id_rsa'
      - '.ssh/id_ed25519'
      - '.kube/config'
      - 'serviceaccount/token'
      - '/.env'
  condition: all of selection_*
falsepositives:
  - Legitimate SDK or tooling initialization referencing credential paths
  - Developer shells sourcing environment files interactively
level: high
---
title: Outbound Connection from Python Process to Rare External Host Post-Install
id: 6b1f9c45-4d78-4a2e-8c63-1f5a7e0d92c8
status: experimental
description: Detects python or pip processes establishing outbound network connections shortly after package installation, a pattern consistent with staged credential exfiltration from a trojanized package. Baseline against known package indexes and artifact hosts.
references:
  - https://thehackernews.com/2026/08/malicious-litellm-releases-tied-to.html
  - https://attack.mitre.org/techniques/T1041/
author: Security Arsenal
date: 2026/08/26
tags:
  - attack.exfiltration
  - attack.t1041
logsource:
  category: network_connection
  product: linux
detection:
  selection:
    Image|endswith:
      - '/python'
      - '/python3'
      - '/pip'
      - '/pip3'
  filter_known_hosts:
    DestinationHostname|contains:
      - 'pypi.org'
      - 'files.pythonhosted.org'
      - 'github.com'
      - '.anaconda.com'
      - 'artifactory.'
      - '.azurewebsites.net'
  condition: selection and not 1 of filter_*
falsepositives:
  - Legitimate application API traffic from Python services — tune per host role and restrict to build agents and recent-install systems
level: medium

// Hunt for installation of the malicious LiteLLM releases across endpoints and CI/CD runners.
// Covers MDE-ingested endpoints (DeviceProcessEvents) and Syslog-ingested Linux hosts.
let MaliciousVersions = dynamic(["1.82.7", "1.82.8"]);
union isfuzzy=true
(DeviceProcessEvents
| where TimeGenerated > ago(180d)
| where FileName in~ ("pip", "pip3", "python", "python3", "uv", "poetry")
| where ProcessCommandLine has_any ("litellm") and ProcessCommandLine has_any (MaliciousVersions)
| project TimeGenerated, DeviceName, InitiatingProcessAccountName, ProcessCommandLine, FileName, ReportId),
(Syslog
| where TimeGenerated > ago(180d)
| where SyslogMessage has_all ("litellm", "install")
| where SyslogMessage has_any (MaliciousVersions)
| project TimeGenerated, HostName, ProcessName, SyslogMessage)
| sort by TimeGenerated asc

-- Hunt artifact: identify installed malicious LiteLLM versions on Linux endpoints
-- by inspecting pip dist-info metadata and recent site-packages modifications.

LET dist_info = SELECT FullPath, Mtime
FROM glob(globs=['/usr/lib/python3*/site-packages/litellm-1.82.7.dist-info/METADATA',
                 '/usr/lib/python3*/site-packages/litellm-1.82.8.dist-info/METADATA',
                 '/usr/local/lib/python3*/site-packages/litellm-1.82.7.dist-info/METADATA',
                 '/usr/local/lib/python3*/site-packages/litellm-1.82.8.dist-info/METADATA',
                 '/home/*/.local/lib/python3*/site-packages/litellm-1.82.7.dist-info/METADATA',
                 '/home/*/.local/lib/python3*/site-packages/litellm-1.82.8.dist-info/METADATA',
                 '/opt/*/lib/python3*/site-packages/litellm-1.82.8.dist-info/METADATA'])

SELECT FullPath AS MaliciousPackageMetadata,
       Mtime AS InstallTimestamp
FROM dist_info

#!/usr/bin/env bash
# LiteLLM supply-chain exposure scanner
# Run on any Linux host, build agent, or container image that may have resolved litellm during the March 2026 window.
# Exit 0 = clean, Exit 1 = MALICIOUS VERSION FOUND (treat as credential-compromise event)

MALICIOUS="1.82.7|1.82.8"
FOUND=0

echo "[*] Checking pip-installed litellm version..."
for PY in python3 python; do
  command -v "$PY" >/dev/null 2>&1 || continue
  VER=$("$PY" -m pip show litellm 2>/dev/null | awk '/^Version:/{print $2}')
  if [ -n "$VER" ]; then
    echo "    $PY -> litellm $VER"
    echo "$VER" | grep -qE "^($MALICIOUS)$" && { echo "[!] MALICIOUS VERSION DETECTED: $VER"; FOUND=1; }
  fi
done

echo "[*] Scanning filesystem for malicious dist-info metadata..."
while IFS= read -r -d '' f; do
  echo "[!] MALICIOUS ARTIFACT: $f"
  FOUND=1
done < <(find /usr /usr/local /opt /home /root /var -type d \
  \( -name "litellm-1.82.7.dist-info" -o -name "litellm-1.82.8.dist-info" \) -print0 2>/dev/null)

echo "[*] Reviewing pip install logs / shell history for the malicious window..."
grep -rEh "litellm[= =]+(1\.82\.7|1\.82\.8)" /root/.bash_history /home/*/.bash_history /var/log/ 2>/dev/null | head -20

if [ "$FOUND" -eq 1 ]; then
  echo ""
  echo "[ACTION REQUIRED] This host installed a malicious LiteLLM release."
  echo "  1. Isolate the host / revoke its network access."
  echo "  2. Rotate ALL secrets reachable from this context: AWS/GCP/Azure keys, SSH keys,"
  echo "     Kubernetes service-account tokens, DB passwords, LLM provider API keys, .env contents."
  echo "  3. Review cloud audit logs (CloudTrail, Azure Activity, GCP Audit) for key misuse from March 2026 onward."
  echo "  4. Rebuild from a clean base image with a pinned, verified litellm version."
  exit 1
else
  echo "[+] No malicious LiteLLM artifacts found on this host."
  exit 0
fi

Remediation

This incident has no patch in the traditional sense — remediation is about removing the malicious artifact and assuming breach of every secret the affected context could reach. Prioritize in this order:

1. Inventory immediately. Query your artifact repositories, lockfiles (requirements.txt, poetry.lock, Pipfile.lock, uv.lock), container image layers, SBOMs, and CI/CD build logs from the March 2026 window for resolution of litellm to the malicious releases. Do not rely on current installed state — ephemeral build runners and short-lived containers may already be gone, but their credentials are not.

2. Rotate every reachable credential on any confirmed-exposed system. This is non-negotiable and includes: AWS/GCP/Azure access keys and session credentials, SSH private keys, Kubernetes service-account tokens and kubeconfig client certs, database passwords, LLM provider API keys (OpenAI, Anthropic, Azure OpenAI, Bedrock, Vertex), and any secret present in environment variables or .env files. Remember that LiteLLM deployments centralize provider keys by design — one exposed proxy can compromise your entire multi-provider AI estate.

3. Review audit trails for post-compromise misuse. Mine AWS CloudTrail, Azure Activity Logs, GCP Audit Logs, and Kubernetes audit logs from March 2026 forward for use of the rotated keys — especially API calls from unrecognized IP space, new IAM principal creation, and anomalous GetSecretValue/AssumeRole activity. CloudSEK's dataset confirms the data left your environment; the question is whether it has been operationalized yet.

4. Rebuild, don't clean. Trojans of this class frequently drop secondary persistence. Any host or image that ran the malicious package should be rebuilt from a known-good base with a pinned, hash-verified dependency set.

5. Harden the pipeline against the next one. Enforce version pinning with hash checking (pip install --require-hashes), route all package resolution through an internal mirror or proxy (Artifactory, Nexus, or a curated allowlist) that does not auto-ingest brand-new releases, deploy pip-audit or equivalent in CI, and adopt a cooldown policy that blocks packages published less than 24–72 hours ago from entering builds. Evaluate Sigstore attestation and PyPI trusted-publishing status for your critical dependencies.

6. Watch the Trivy thread. Because this campaign stems from the Trivy compromise, audit anywhere Trivy or its GitHub Actions run in your pipelines, and rotate any credentials those workflows held. Cascading supply-chain incidents rarely stop at one downstream victim.

If you confirm exposure and lack the internal bandwidth to scope 434,000-file-scale exfiltration against your own audit logs, engage an IR retainer — the delta between "keys stolen" and "keys used" is measured in days, not months.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub