Am I Compromised by LiteLLM? A Fast Supply Chain Check

If your organization installed LiteLLM from PyPI on March 24, 2026, you may be asking: “Have I been compromised by LiteLLM?”

The short answer is: check immediately if LiteLLM 1.82.7 or 1.82.8 was installed or executed in your environment. These malicious releases were tied to the wider TeamPCP supply-chain campaign and were designed to steal cloud credentials, SSH keys, Kubernetes tokens, database passwords, API keys, and other secrets.

This is a short triage guide for searches such as LiteLLM compromised, LiteLLM supply chain attack, am I affected by LiteLLM, and was LiteLLM hacked?

Which LiteLLM versions were compromised?

The affected PyPI releases were:

• litellm==1.82.7
• litellm==1.82.8

LiteLLM reported that the releases were live on March 24 from approximately 10:39 UTC for about 40 minutes. The project recommends treating installations made on March 24 up to 16:00 UTC as potentially exposed while investigating the exact package source and execution history.

Version 1.82.8 included a malicious litellm_init.pth file. Python processes .pth files at interpreter startup, which means the payload could execute when Python started even if the application did not explicitly import LiteLLM.

The malware targeted environment variables, cloud credentials, SSH files, Git credentials, Kubernetes tokens, database configuration, and other secrets before sending collected information to models.litellm[.]cloud, a domain unrelated to the official LiteLLM project.

For a deeper technical breakdown, read How TeamPCP Compromised LiteLLM.

How do I check if I am compromised by LiteLLM?

Use these steps in order:

1. Check the CloudSEK public lookup

CloudSEK published a public lookup for organizations associated with files and logs obtained during the AI supply-chain incident:

Search the CloudSEK AI supply-chain incident lookup

Search by your organization name or domain, then review the confidence label, exposed-secret count, and run count. A match is an exposure lead, not automatic proof that a named organization was breached or that every listed secret remains valid. Treat both High and Medium results seriously and verify them against your own logs.

If the embedded lookup does not load, use the direct CloudSEK public lookup link. Browser security policies, framing restrictions, or future changes to the CloudSEK site may prevent the iframe from displaying.

2. Search package and build records

Search PyPI, dependency-lock files, package caches, CI/CD logs, Docker image layers, virtual environments, and artifact repositories for 1.82.7 or 1.82.8.

# Search the current environment
python -m pip show litellm
python -m pip freeze | grep -i '^litellm=='

# Search a repository and local build records
grep -RInE 'litellm([=<>!~ ]+|/).*1\.82\.(7|8)' . 2>/dev/null

Also look for litellm_init.pth under Python site-packages directories. Package presence alone does not prove that secrets were exfiltrated, but execution during the exposure window should be treated as a security incident.

3. Hunt for stolen-secret indicators

Review network, DNS, endpoint, GitHub, cloud, and Kubernetes telemetry for suspicious activity after the package was installed or executed. Prioritize:

• outbound connections to models.litellm[.]cloud;
• unexpected use of cloud access keys, API keys, SSH keys, PATs, or publishing tokens;
• newly created repositories with names beginning tpcp-docs- or related TeamPCP indicators;
• release assets named data-<timestamp>;
• unusual Kubernetes privileged pods, service accounts, or node-level activity; and
• unexpected package publishing, repository, or cloud IAM events.

The public lookup may help identify an exposure path, but your own package, process, identity, and network telemetry should determine the incident scope.

What should I do if LiteLLM 1.82.7 or 1.82.8 was installed?

Assume the environment may be compromised and take these actions:

1. Isolate the host or runner: Stop using the affected virtual environment, container, CI runner, or developer workstation for new builds or deployments.
2. Rotate exposed credentials: Revoke and replace cloud keys, API keys, SSH keys, database passwords, Kubernetes tokens, Git credentials, PyPI tokens, and CI/CD secrets that were accessible to the process.
3. Use a clean environment: Rebuild from a trusted base image or clean host rather than simply uninstalling LiteLLM.
4. Inspect persistence: Check Python startup paths, shell profiles, system services, scheduled tasks, Kubernetes objects, and CI/CD changes for unauthorized modifications.
5. Review downstream activity: Search cloud audit logs, Git provider logs, registry logs, DNS logs, and egress telemetry for actions made with the exposed identities.
6. Upgrade safely: Install a verified, non-affected LiteLLM release using a lockfile, trusted package source, integrity checks, and a controlled deployment pipeline.

Do not wait for proof of credential misuse before rotating secrets. A long-lived credential copied during the exposure window can remain usable long after the malicious package has been removed.

The upstream Trivy TeamPCP compromise is important context because the LiteLLM incident was reported as part of a broader campaign involving CI/CD and package-publishing credentials.

Is every LiteLLM user compromised?

No. Installing LiteLLM does not automatically prove that your organization was compromised, and using LiteLLM Cloud is not the same as installing the affected PyPI packages. Risk depends on the exact package version, installation time, whether the package executed, the secrets available to the host, and evidence from your logs.

However, if 1.82.7 or 1.82.8 ran in an environment with valuable credentials, the safest response is to treat those credentials as exposed until you complete the investigation.

This incident is also separate from the later LiteLLM authentication-bypass vulnerability. The supply-chain incident concerns malicious PyPI releases; the authentication issue concerns an exposed LiteLLM proxy and a separate vulnerability class.

LiteLLM compromise: quick decision table

Finding	Recommended response
No affected version found and no public lookup match	Continue monitoring and verify dependency provenance.
Affected version present but never executed	Remove it, rebuild from a clean environment, and review accessible secrets.
Affected version executed on a developer or CI/CD host	Rotate all accessible secrets and investigate identity, network, and persistence logs.
CloudSEK lookup match	Treat it as a high-priority exposure lead; validate against internal evidence and rotate potentially exposed credentials.
Evidence of models.litellm[.]cloud traffic or unauthorized identity activity	Activate incident response and preserve forensic evidence before rebuilding.

The practical lesson for AI supply-chain security

The LiteLLM incident shows why package names and lockfiles are not enough. Security teams also need trusted package provenance, short-lived credentials, isolated builds, dependency monitoring, egress controls, runtime detection, and a tested rotation playbook.

Use the Verify First Playbook for defending the software supply chain to strengthen package, CI/CD, artifact, and credential controls before the next dependency compromise.

To further enhance your cloud security and implement supply chain security, contact me on LinkedIn Profile or [email protected].

Frequently Asked Questions (FAQ)

Am I compromised by LiteLLM?

You may be at risk if LiteLLM 1.82.7 or 1.82.8 was installed or executed on March 24, 2026. Check package records, CI/CD logs, Python site-packages directories, the CloudSEK public lookup, and network and identity logs. If an affected version ran, rotate all credentials it could access.

Which LiteLLM versions were compromised?

LiteLLM versions 1.82.7 and 1.82.8 were identified as malicious PyPI releases connected to the TeamPCP supply-chain campaign.

How can I check whether LiteLLM malware ran in my environment?

Search dependency files, package caches, CI/CD logs, containers, virtual environments, and Python site-packages for LiteLLM 1.82.7, LiteLLM 1.82.8, and litellm_init.pth. Then review process, DNS, egress, cloud audit, Git, and Kubernetes logs for suspicious activity.

What is the CloudSEK LiteLLM exposure lookup?

CloudSEK published a searchable lookup at exposure.cloudsek.com/ai-supply-chain-incident. It lists organizations associated with captured files and logs from the incident and includes confidence labels, secret counts, and run counts. Results should be treated as exposure leads and validated against internal evidence.

What should I do if LiteLLM 1.82.7 or 1.82.8 was installed?

Isolate the host or runner, preserve relevant evidence, revoke and rotate all accessible cloud and application credentials, rebuild from a clean environment, inspect persistence and downstream activity, and redeploy a verified LiteLLM release using trusted package and CI/CD controls.

Is the LiteLLM supply-chain attack the same as the LiteLLM authentication bypass?

No. The LiteLLM supply-chain attack involved malicious PyPI releases 1.82.7 and 1.82.8. The LiteLLM authentication bypass is a separate vulnerability affecting exposed proxy deployments. Organizations should investigate both risks independently.

This article summarizes public reporting and CloudSEK’s public lookup. A lookup result is not, by itself, proof that an organization was breached or that a credential was used. Validate findings with your incident-response team and rotate potentially exposed secrets.