How do I know if my organization was affected by the LiteLLM supply chain attack?

An environment is affected if litellm 1.82.7 or 1.82.8, published to PyPI on 24 March 2026, was installed, built or deployed in it. Any secret present in that environment at the time, including API keys, cloud credentials, SSH keys and Kubernetes tokens, should be assumed exposed regardless of whether it appears in the index yet.

Which LiteLLM versions were compromised?

The compromised releases are litellm 1.82.7 and 1.82.8, published to PyPI on 24 March 2026. Both should be removed immediately, and LiteLLM should be pinned to a trusted version, either the last known-good release published before the attack or a patched release issued afterwards.

Is the LiteLLM exposure check free to use?

Yes. Checking a domain is free and requires no account. Results shown are estimated from Whiteintel's indexed data; the full itemised list of exposed secrets is released through a responsible-disclosure process to a verified owner of the domain, which prevents one organization from retrieving another's leaked secrets.

Does a result of no exposure found mean an environment is safe?

No. It means Whiteintel has not indexed leaked credentials for that domain at this time, and new data surfaces continuously. Any environment that ran an affected LiteLLM version should still rotate every secret that was present, because absence from the index is not evidence that a secret was not exfiltrated.

What should be done if a domain is exposed in the LiteLLM attack?

Rotate and revoke every potentially affected secret: reissue API keys and cloud credentials, invalidate SSH keys and Kubernetes tokens, audit access logs for misuse occurring after 24 March 2026, and remove the malicious LiteLLM versions from all environments and build pipelines. Rotation should cover any secret present in the environment, not only those appearing in the check.

How current is the LiteLLM exposure data?

Whiteintel indexes exposed secrets and dark web data continuously, so results reflect the latest indexed state at the time of the query. Because leaked secrets continue to surface after an incident, a domain should be re-checked periodically rather than treated as cleared by a single negative result.

LiteLLM Supply Chain Attack: Free Exposure Check

In short

The LiteLLM Supply Chain Exposure Check is a free tool that tells you whether credentials tied to your domain were leaked in the LiteLLM supply chain attack: the malicious litellm 1.82.7 and litellm 1.82.8 packages published to PyPI on March 24, 2026, which harvested API keys, cloud credentials, SSH keys and Kubernetes tokens from affected environments. Enter your domain above, complete the captcha, and Whiteintel searches its index of exposed secrets for a match. Results are estimated; for the full, itemized list we provide a responsible, ethical disclosure to the verified owner.

What was the LiteLLM supply chain attack?

On March 24, 2026, two trojanized versions of the popular open-source LLM gateway LiteLLM, 1.82.7 and 1.82.8, were published to the Python Package Index (PyPI). Anyone who installed or deployed those releases ran attacker-controlled code that exfiltrated secrets from the host environment. Because LiteLLM commonly sits in front of production AI infrastructure, the packages had access to exactly the credentials attackers want most: model-provider API keys, cloud access keys, SSH keys and Kubernetes service-account tokens.

The malicious releases were live only briefly, but the blast radius is outsized: a single leaked cloud key or Kubernetes token can unlock an entire environment. For the full timeline, indicators of compromise and affected-version details, read our LiteLLM supply chain attack advisory. LiteLLM supply chain attack.

How the exposure check works

1
Enter your domain. For example yourcompany.com. No account or email is required.
2
Complete the captcha. Confirms you are human and protects the service from abuse.
3
Review your exposure summary. Whiteintel searches its index of secrets leaked in the LiteLLM attack and returns an estimated count of exposed files, secrets and credential types.
4
Rotate and request full disclosure. Rotate every affected secret, then contact our team for the complete, itemized list under responsible disclosure.

What kind of secrets were exposed?

The malicious LiteLLM packages targeted high-value credentials that are typically present in AI and cloud environments, including:

Model-provider API keys. OpenAI, Anthropic and other LLM API keys.
Cloud credentials. AWS, GCP and Azure access keys and secrets.
SSH keys. Private keys granting server access.
Kubernetes tokens. Service-account tokens and cluster credentials.

What to do if your domain is exposed

Rotate every secret: that could have been present where an affected LiteLLM version ran. Assume all are compromised.
Revoke and reissue: API keys, cloud access keys, SSH keys and Kubernetes tokens; invalidate active sessions.
Pin to a known-good release: remove 1.82.7 / 1.82.8 and pin LiteLLM to a version you trust.
Audit for misuse: review cloud, provider and cluster logs for unauthorized access after March 24, 2026.
Get the full list: contact Whiteintel for a responsible disclosure of exactly which of your secrets were found.

Frequently asked questions

The LiteLLM Supply Chain Exposure Check is a free tool from Whiteintel that searches its index of secrets leaked in the LiteLLM supply chain attack for credentials tied to a given domain. The attack distributed malicious litellm packages 1.82.7 and 1.82.8 on PyPI, and any secret present in an environment that installed them should be treated as compromised.

Rotating isn't enough. Find out what already leaked.

Whiteintel monitors the dark web for exposed credentials, infostealer logs and leaked secrets so you can act before attackers do.

Start monitoring free Contact for full disclosure

Product

Free tools

Resources

Start monitoring in minutes

Identity & access

Brand & external

Partners & research

See what's exposed

Were you exposed in the LiteLLM supply chain attack?