LiteLLM 1.107.0 could run credential-stealing malware when Python started

What LiteLLM confirmed

LiteLLM's incident notice [1] says its release pipeline published malicious version 1.107.0 to PyPI and official container registries on October 21. All seven wheels were available from 11:39:51 to 13:23 UTC.

Docker Hub tags v1.107.0, latest, main-latest and main-stable pointed to the compromised image index from 11:46:56 to 14:20 UTC. Matching GHCR tags were also affected until LiteLLM made them unavailable by 13:51 UTC.

For this October incident, LiteLLM identified 1.107.0 as the affected public release and named 1.106.2 as a clean recovery target. Its private enterprise release was not affected. The public GitHub source tag for v1.107.0 did not contain the malicious files because the attacker changed what the release workflow built.

Why a normal Python command could run the malware

Microsoft's independent payload analysis [2] found cook.pth, cook.py and sitecustomize.py inside the wheels. Installation placed them in the Python environment's library directory, where Python processes .pth files and imports sitecustomize during startup.

An application did not have to import LiteLLM. Starting Python could launch the credential collector, and the sitecustomize component could keep a background process running to fetch and execute more Python code.

Microsoft observed matching discovery, encryption and outbound-connection behavior on Windows and macOS endpoints. In one case, a Python process installing an unrelated dependency activated the collector.

What the attackers tried to steal

The collector searched for authentication material used by cloud platforms, model providers, developer tools, infrastructure software and browsers. When configuration gave it database access, it also tried to read selected credentials and model configuration from a LiteLLM proxy database.

Datadog Security Labs independently analyzed the artifacts [4] and found that cook.py encrypted collected data before sending it to a lookalike LiteLLM domain. Datadog also found a second component that checked a GitHub-hosted dead drop for instructions and could download more Python code.

Removing the bad package can stop future execution, but it cannot retract secrets that were already copied. Affected teams should treat cloud roles, model-provider keys, database passwords, proxy keys and other process-accessible secrets as exposed.

How the trusted release path was abused

LiteLLM's later attack-chain report [3] traces the first access to a master key committed to a public repository in May. On October 10, the attacker used that key against an internal service and obtained an organization owner's GitHub CLI token.

The attacker then used repository workflows to copy more maintainer tokens, changed the private release workflow, and pointed a staging build at Berri-AI/litellm. The legitimate organization is BerriAI, without the hyphen.

A second stolen maintainer token satisfied the production approval gate. A third token deleted release-run records. The pipeline then built and published the poisoned artifacts through channels users already trusted. LiteLLM says this later report corrects assumptions in its initial incident updates about where the first token came from.

LiteLLM has not attributed the attack to a named group. Datadog says no connection has been established between this incident and the project's earlier 2026 compromise.

What operators should do now

First identify whether any environment installed litellm 1.107.0 or ran one of the mutable container tags during the affected window. Include developer machines, CI runners, proxy hosts, image caches, internal registries and build outputs.

Do not begin by running pip, Python or a LiteLLM command inside a suspect environment. Python startup can execute the malicious files again. Inspect disks and images from outside the affected runtime, or preserve them for incident responders.

Build a new environment from known-clean inputs and pin litellm 1.106.2, which LiteLLM named as the clean recovery version. Pin container images by a verified clean digest instead of relying on a mutable tag.

• Isolate affected hosts from the network, preserve disks and container artifacts for investigation, then stop compromised workloads.
• Search package inventories, lockfiles, caches, mirrors and image layers for version 1.107.0.
• Look for litellm-1.107.0.dist-info, cook.pth, cook.py, sitecustomize.py, /tmp/.pc_once_72129118c59f5636c0bb and /tmp/remote_code_loader.lock, but do not treat their absence as proof that a host is clean.
• Rebuild virtual environments and images instead of cleaning them in place when possible.
• Rotate cloud credentials, model-provider keys, LiteLLM master and virtual keys, database passwords, SSH keys and other secrets reachable from the affected identity.
• Rotate credentials from a clean machine and revoke old sessions or tokens before restoring service.
• Review cloud, provider, GitHub, database and network logs for use from unfamiliar systems after the exposure.
• Check internal artifacts so a quarantined public release cannot return through a cache or mirror.

What is confirmed and what remains uncertain

• Confirmed: all seven PyPI wheels for version 1.107.0 contained the malicious payload.
• Confirmed: official Docker Hub and GHCR tags distributed compromised image indexes during documented windows.
• Confirmed: Python startup could execute the payload without an application importing LiteLLM.
• Confirmed: the production pipeline signed and published artifacts built from a commit in the lookalike repository after attackers obtained several privileged tokens.
• Confirmed: LiteLLM pulled or repointed the affected artifacts and revoked involved credentials.
• Uncertain: how many users pulled or ran the artifacts before removal.
• Uncertain: which stolen credentials attackers used after collection in each affected organization.
• Uncertain: who carried out the attack and whether it is connected to earlier LiteLLM incidents.

How this changes AI gateway operations

An AI gateway concentrates model-provider keys, routing rules, database access and workload identities. Teams should therefore classify its release artifacts and maintainer tokens as privileged infrastructure rather than ordinary application dependencies.

A version pin limits which package resolver result you receive, but it does not prove that the resolved artifact came from reviewed source. Record hashes or image digests, retain software bills of materials, and verify provenance independently before promotion.

Release approvals should confirm the source repository, commit and artifact digest. Approval by a second account provides little protection when the workflow can expose that account's token or when both accounts can authorize an unexpected repository.

Frequently asked questions

• Was every LiteLLM version affected? No. The October incident notice identifies public version 1.107.0 and specific mutable image tags during defined windows. LiteLLM identified 1.106.2 as clean for recovery, and its private enterprise release was not affected.
• Am I safe if my code never imported LiteLLM? No. Python could execute the installed startup files before an import from application code.
• Can I run pip show to check the version? Avoid starting Python or pip inside a suspect environment. Check files, images, inventories and deployment records from a clean system.
• Does deleting LiteLLM finish recovery? No. Rebuild the environment, stop surviving processes, rotate reachable credentials and review logs for misuse.
• Is a missing /tmp/.pc_once_72129118c59f5636c0bb marker proof that nothing ran? No. LiteLLM warns that containers and temporary-file cleanup may remove it.
• Should I switch back to latest after the tag was repointed? Use an explicit reviewed version and verified digest. A mutable tag can point to different content over time.