LiteLLM 1.107.0 Was Malware. Are Your AI Keys Exposed?

October 23, 2026

LiteLLM's official 1.107.0 release stole cloud, developer, and AI credentials. Check the exact affected artifacts, exposure windows, and recovery steps.

LiteLLM version 1.107.0 was a malicious release, not merely a vulnerable one. On October 21, 2026, LiteLLM's official PyPI and container channels briefly distributed a credential stealer and remote code loader. If that exact wheel ran, or an affected Docker or GHCR tag started during the published exposure window, treat the environment as compromised, rebuild it from a known-clean source, and rotate every reachable secret from a separate clean machine.

The incident matters beyond one package. LiteLLM is an AI gateway that often sits beside provider API keys, cloud identities, database credentials, developer tools, and prompts. The poisoned release used Python startup hooks, so the malware could execute when Python started even if the application never imported LiteLLM. A clean Git tag also did not prove the installed wheel was clean.

This is an active incident with a confirmed affected version and bounded distribution windows. It is not evidence that every LiteLLM deployment was breached, that OpenAI or Anthropic was compromised, or that every AI chat product exposed customer conversations. The right response starts with artifact identity and execution evidence—not panic, package-name matching, or vague AI-security claims.

What Is Confirmed

LiteLLM's primary incident report says its release pipeline was compromised on October 21. The project confirmed that malicious artifacts were published through its normal public distribution channels and later removed.

The confirmed public exposure was narrow enough to test precisely:

Distribution path Confirmed affected artifact Published exposure window on October 21, 2026
PyPI All seven litellm==1.107.0 wheels 11:39:51 to 13:23 UTC
Docker Hub v1.107.0, latest, main-latest, and main-stable 11:46:56 to 14:20 UTC
GitHub Container Registry The same four tags across named LiteLLM images 11:46:56 until unavailable by 13:51 UTC

LiteLLM says all earlier versions are safe from this specific incident. It also says customers pulling its private enterprise-registry release were not affected. That distinction matters: a company can use LiteLLM without having installed the poisoned public artifact.

The project's confirmed affected Docker image index was:

sha256:1bbcb1443bc962e4​5f5aad53fe3d2c30​600e0379715fb6c6​64cdd3ac126c339e

LiteLLM's report says the official GitHub source tag for 1.107.0 did not contain the malicious files. The released wheels and containers were built from an attacker-controlled lookalike repository named Berri-AI/litellm, while the legitimate organization is BerriAI/litellm.

Independent analysis reinforces the artifact-level finding. JFrog Security Research found three extra startup files in all seven wheels, across macOS, Linux, musl Linux, and Windows targets. Socket says its scanner flagged the release seven minutes after publication. Datadog Security Labs separately analyzed the credential stealer, the remote loader, the affected artifacts, and the containment steps.

The malware could start before LiteLLM was imported

The poisoned wheels installed three files into the Python environment's site-packages root:

Python processes .pth files and sitecustomize.py during interpreter startup. That means starting Python, running an application in the environment, or invoking environment-local tooling could execute the payload. An operator did not need to write import litellm first.

This also changes the cleanup logic. Deleting only the normal litellm package directory can leave the startup files behind. LiteLLM specifically warns users not to begin remediation by running pip, because that starts Python and can execute the malicious startup hooks again.

The stealer targeted more than AI provider keys

The credential collector searched broadly. The published analyses describe targets including:

This list does not prove that every item was present or stolen on every affected host. It identifies what the malware attempted to collect from data and interfaces it could reach.

The second component created a remote-code path

The sitecustomize.py component periodically checked a GitHub-hosted file for a command-and-control domain and could download and execute another Python payload. JFrog reported that the remote pointer was empty when it checked, so it did not observe a second-stage payload delivered through that channel at that moment.

That does not make the release harmless. The credential stealer operated independently, and the loader created a channel that could be activated later. A time-bounded observation that the remote pointer was empty is not proof that every affected environment avoided code execution or data loss.

The attack used the real release workflow

LiteLLM's current reconstruction says the attacker held GitHub CLI credentials associated with three developers. The attacker first tried to alter the private release workflow through normal review, then used an organization-owner credential to override branch protections and force-push the change.

The modified workflow pointed staging and production at the lookalike repository. A second credential approved the production gate. A third was used to delete workflow records after the artifacts were published.

The result was especially deceptive: the artifacts traveled through official channels and were signed by the project's release system, while the public source tag remained clean. Signing established which workflow produced the artifact; it did not establish that the workflow had used the intended source.

Are You Affected?

The most useful question is not “Do we use LiteLLM?” It is “Did a confirmed poisoned artifact execute in an environment we control?”

Use this decision sequence.

1. Identify the exact artifact

For Python environments, determine whether litellm==1.107.0 was installed. For containers, inspect the executed image digest, not only the current meaning of a mutable tag.

You should treat the environment as affected if either condition is true:

Pulling a clean image after containment does not rewrite the history of a container that already ran. Likewise, seeing that latest is clean now does not prove what latest resolved to at deployment time.

2. Check execution, not just download history

A cached wheel or image that never executed presents a different risk from one that started with access to production credentials. Inventory CI runners, developer laptops, build hosts, containers, notebooks, virtual environments, and gateway nodes.

Useful evidence includes:

LiteLLM cautions that the absence of a marker file does not prove safety. Containers can be replaced, temporary files can disappear, and cleanup may remove evidence even after data left the host.

3. Map what the process could reach

Exposure is a graph, not a list. Start with the identity of the affected process and follow each accessible edge:

If the host had outbound internet access, LiteLLM says to assume exfiltration succeeded. Rotate based on reachability, not based only on which secret names appear in a public malware summary.

4. Do not confuse “not proven” with “not affected”

The incident report gives strong positive indicators. It does not offer one negative test that clears a system with certainty. A missing file, an empty command-and-control pointer, or a clean source tag cannot undo prior execution.

When the affected artifact ran beside valuable credentials, rebuilding and rotating from a clean administrative plane is safer than trying to prove a negative from an environment the malware controlled.

What Should You Do Now?

Follow your incident-response process and the maintainer's current guidance. The sequence below organizes the work; it is not a substitute for a qualified responder who can examine your environment.

1. Stop and isolate affected workloads

Prevent additional Python starts in the suspected environment. Isolate affected hosts or workloads from external networks and sensitive internal services while preserving evidence appropriate to your incident policy.

Do not run the affected environment's own python or pip as your first diagnostic step. Those commands can trigger the startup hooks.

2. Preserve the evidence you will need

Record image digests, package hashes, process trees, filesystem timestamps, container events, deployment times, network telemetry, cloud audit logs, and credential-use logs before destructive cleanup.

Capture which secrets were available to each affected execution identity. A complete scope map is more valuable than a screenshot showing that the package version was installed.

3. Rebuild from a known-clean source

LiteLLM's report recommends pinning to 1.106.2 for the time being and says rebuilding images and virtual environments from scratch is better than in-place cleanup. Use the project's newest verified guidance if it changes after this article's research cutoff.

If in-place removal is unavoidable, LiteLLM says the malicious startup files and matching bytecode must be removed from every affected site-packages directory, and the detached loader process must be stopped. That step is containment—not proof that stolen credentials are safe.

4. Rotate reachable secrets from a clean machine

Rotate from an administrative system that did not run the poisoned artifact. Prioritize credentials that provide broad or reusable authority:

  1. cloud workload and instance identities;
  2. GitHub, Git, registry, CI/CD, and package-publishing tokens;
  3. LiteLLM master, virtual, and upstream provider keys;
  4. database passwords and secret-store credentials;
  5. SSH, GPG, TLS, and signing keys;
  6. AI coding-tool sessions and tokens; and
  7. browser sessions and saved credentials reachable from an affected workstation.

Revocation must address copies, derivatives, and cached sessions. Replacing an OpenAI API key, for example, does not invalidate an unrelated cloud role or browser cookie that was collected from the same machine.

5. Hunt for post-exfiltration use

Search cloud, identity, repository, registry, provider, database, and billing logs for unusual activity after exposure. LiteLLM specifically recommends checking AWS CloudTrail for GetCallerIdentity around installation and for later use of the role outside expected infrastructure.

Wiz told The Hacker News that it observed some stolen AWS credentials validated roughly 4.5 hours after exfiltration, followed by model-listing and limited discovery calls. That reporting is evidence of post-theft use in some environments, not proof that every affected credential was used.

Review AI-provider usage and billing as carefully as cloud-control-plane activity. Stolen provider keys can support unauthorized inference, unexpected cost, access to gateway-visible configuration, or a path into connected systems depending on the key's scope.

6. Check downstream systems and obligations

Determine whether the affected gateway logged prompts, responses, tokens, user identifiers, or connected-system data. If personal data, customer secrets, regulated information, or another organization's credentials may have been exposed, involve legal, privacy, insurance, and notification teams under your established process.

Do not wait for proof that every record was viewed before beginning the scope analysis. Notification duties and contractual timelines may be triggered by risk, access, or compromise rather than a perfect forensic reconstruction.

What Is Still Unclear

The main incident is confirmed, but several material questions remain open as of the research cutoff.

Initial access is not confirmed

LiteLLM says it observed circumstances in which Claude Code could embed a user's GitHub CLI OAuth token in a response body and those bodies could appear in LiteLLM logs. The project also found an unexpected user account in an internet-exposed internal LiteLLM deployment and believes the attacker obtained developer tokens from logs there.

The project has not confirmed how the attacker first accessed that deployment. It currently suspects a recently patched vulnerability. That is an investigation theory from the victim, not a finished root-cause finding.

The evidence does not establish that Claude Code independently attacked LiteLLM, that Anthropic was breached, or that every Claude Code response exposes GitHub tokens. The disclosed chain requires a specific token-handling behavior, logging, access to those logs, and sufficient GitHub authority.

The number of affected users is not public

Download estimates show LiteLLM is widely used, but a weekly download count cannot tell us how many organizations fetched 1.107.0 during a two-hour window, how many ran it, or which secrets were reachable.

Automated mirrors, caches, security scanners, CI jobs, and repeated downloads can inflate package statistics. Conversely, mutable container tags can hide historical exposure after they are repointed. Affected-user counts require registry, telemetry, and customer evidence that has not been published in one complete dataset.

Full exfiltration impact is still being investigated

Researchers published a detailed target list and some post-exfiltration observations. The complete set of collected credentials, victim systems, downstream access, and attacker actions is not public.

An environment may be compromised even if no later malicious use is visible yet. Stolen secrets can be sold, stored, tested slowly, or used through infrastructure that blends with legitimate traffic.

Attribution is unresolved

LiteLLM suffered a different supply-chain compromise earlier in 2026. The October payload also used a Python .pth startup mechanism, but JFrog, Socket, and other researchers say the public evidence does not establish that the same actor caused both incidents.

Shared technique is not shared identity. Treat claims that a named group “did it again” as unconfirmed unless the maintainers or investigators publish stronger attribution evidence.

The incident page may change

LiteLLM labeled the event contained while saying the investigation remained in progress. Teams should use the primary incident page as the operational source of truth and recheck it for updated indicators, affected artifacts, root cause, and remediation instructions.

Why A Clean Git Tag Was Not Enough

This incident separates four things teams often collapse into one:

  1. Source identity: Which repository and commit were intended?
  2. Build identity: Which source tree did the build actually consume?
  3. Artifact identity: What exact bytes were published and installed?
  4. Runtime identity: What exact wheel or image executed with which permissions?

The legitimate 1.107.0 source tag did not contain the three malicious files, yet the wheels installed them. The official pipeline signed and distributed artifacts built from a lookalike repository. Reviewing the intended repository therefore could not establish the safety of the installed bytes.

A stronger control chain binds each step to the next:

Digital signatures remain useful. They should answer “which identity signed these bytes?” They cannot answer “were these bytes produced from the intended source under an uncompromised policy?” unless the surrounding workflow, provenance, and authorization controls are also verified.

Use The KEYS Test For AI Gateway Incidents

The KEYS test turns the incident into a reusable four-part review.

K — Know the artifact

Record versions, wheel hashes, image digests, registries, install times, execution times, and source provenance. Never clear a mutable tag merely because it points to a clean image now.

E — Enumerate reachable secrets

Map process identity, environment variables, mounted volumes, instance metadata, databases, developer sessions, provider keys, and browser stores. Scope rotation to what the workload could read—not only what its application was designed to use.

Y — Yank and rebuild

Stop the affected workload, preserve evidence, remove it from service, and rebuild from a verified source. Package removal alone is not recovery when startup hooks, background processes, stolen credentials, or modified downstream resources may remain.

S — Search for secondary use

Correlate identity, cloud, provider, repository, registry, database, network, and billing logs. Continue monitoring after rotation because an attacker may have used one credential to create another durable foothold.

The test is deliberately short because incident response gets noisy. If a team cannot state the artifact, the reachable secrets, the rebuild boundary, and the secondary-use evidence, it does not yet know whether recovery is complete.

Where OpenVeil Fits, And Where It Does Not

OpenVeil is a hosted, privacy-focused AI workspace for adults. Its normal private chat history is stored in the user's browser, and OpenVeil does not maintain a normal server-side chat-history account record. It also does not use prompts, uploads, images, audio, selected local history, or AI outputs to train foundation models.

For someone who wants AI chat, files, search, voice, images, video, and personas without deploying and maintaining a self-hosted multi-provider gateway, that narrower operational model can remove the need to manage a LiteLLM installation, its release pipeline, and its provider-key database personally. See the tradeoffs in Private AI Chat vs Local AI.

That is the genuine connection. It is not a claim that hosted software has no supply-chain risk.

OpenVeil is not a LiteLLM vulnerability scanner, malware remover, package registry, credential vault, cloud-security tool, incident-response service, or protection for a compromised developer machine. This article does not establish whether any particular hosted service uses LiteLLM internally. Active requests still require processing by OpenVeil and necessary AI, search, upload-processing, hosting, routing, security, billing, and infrastructure providers.

Browser-local history also does not protect a secret intentionally pasted into an active request, secure an unrelated gateway, or undo credential theft from another system. If a poisoned package ran in your environment, follow the maintainer's incident guidance and your response process.

For the broader architectural question, read AI Server Attacks Are Rising: LiteLLM, MCP, and Prompt Injection. For API-key scope and billing risk, see An AI Agent Leaked an API Key and Burned $600,000 in Credits.

Frequently Asked Questions

Was every LiteLLM version malware?

No. LiteLLM confirms litellm==1.107.0 as the affected PyPI release for this incident. It says earlier versions are safe from this compromise and directs users to pin 1.106.2 while following current project guidance.

Was every LiteLLM 1.107.0 download compromised?

The project says all seven public PyPI wheels for 1.107.0 were malicious. The official GitHub source tag was clean, and private enterprise-registry customers were not affected. Risk depends on the exact artifact and whether it executed.

If I never imported LiteLLM, am I safe?

Not necessarily. The poisoned wheel installed Python startup hooks that could execute when Python started, before an application imported LiteLLM. Determine whether the environment's interpreter ran after installation.

If the marker files are gone, am I safe?

No single missing marker proves safety. Containers and temporary files can disappear, and cleanup can remove local evidence after secrets were transmitted. Use package, image, deployment, network, identity, and audit evidence together.

Is upgrading enough?

No. Upgrading can remove the malicious package from future execution, but it does not revoke credentials that may already have been stolen, undo attacker actions, or clear persistence elsewhere. Rebuild, rotate, and hunt from a clean administrative environment.

Did Claude Code cause the LiteLLM breach?

That is not confirmed. LiteLLM says it observed specific cases where Claude Code embedded a GitHub CLI OAuth token in a response body and believes logged response data exposed tokens to the attacker. The initial access to its internal deployment remains unconfirmed. This does not establish a breach of Anthropic or autonomous malicious action by Claude.

Were OpenAI, Anthropic, or Google breached?

The reviewed sources do not report a breach of those model providers. The malware targeted provider keys and AI-tool sessions stored or reachable in victim environments. Theft of a customer key is not the same event as compromise of the provider's own systems.

Does using a signed image prevent this kind of attack?

Not by itself. The compromised artifacts were published through the real workflow after that workflow was pointed at a lookalike repository. Signature verification must be paired with source-identity policy, build provenance, independent approval, exact digest pinning, and artifact inspection.

Were mutable container tags part of the risk?

Yes. latest, main-latest, and main-stable temporarily referenced the poisoned image. Pinning a digest makes runtime identity easier to prove, although it does not make a malicious digest safe.

Does browser-local AI chat history solve this problem?

No. Browser-local history changes where a normal conversation archive is kept. It does not secure Python packages, registries, CI workflows, cloud identities, or AI gateways. Storage architecture and software supply-chain security are separate boundaries.

Bottom Line

LiteLLM 1.107.0 was a confirmed malicious public release. Its seven PyPI wheels and affected official container tags carried a credential stealer and a remote code loader. Because the payload used Python startup hooks, it could run before LiteLLM was imported, and because the official source tag was clean, repository review alone could miss the installed malware.

If the affected artifact executed, isolate the workload, preserve evidence, rebuild from a verified clean source, rotate every reachable secret from a clean machine, and investigate downstream use. Do not treat a missing marker, a clean current tag, or an ordinary upgrade as proof of recovery.

The durable lesson is architectural: AI gateways concentrate secrets and authority, while release systems can faithfully sign the wrong source if their control plane is compromised. Know the exact artifact, enumerate its reachable secrets, rebuild the execution boundary, and search for secondary use.

Sources

Research cutoff: October 23, 2026.

When privacy, account control, uploads, and search matter, OpenVeil gives you a private AI workspace designed for that job.