Skip to content

Back to the catalog

Muscle AI (@themuscleai) on X
x.comthread

Muscle AI (@themuscleai) on X

Post on the LiteLLM 1.107.0 PyPI compromise published 21 October 2026 and quarantined about 1 hour 43 minutes later. A malicious .pth file ran at Python startup and stole cloud credentials, private keys, browser data and AI tool auth files, then POSTed a tarball to an attacker endpoint. The author says attackers used stolen GitHub CLI OAuth tokens to push a trojanized commit chain and build official wheels. It lists five defenses: hash-pinned lockfiles, per-tool capped keys, release cooling periods, secret isolation and egress monitoring.

TL;DR Recounts the LiteLLM 1.107.0 PyPI credential-stealer release via a hijacked release pipeline and gives a five-point dependency hardening checklist.
Open original ↗
Also seen from another angle🧠 AI →
Document

What it is

LiteLLM 1.107.0 was a malicious release on PyPI, published at 7:39 AM on 21 October 2026 and quarantined by PyPI about 1 hour 43 minutes later. The source is an X post by @themuscleai, a single-author account with no linked advisory. The post gives LiteLLM about 92M monthly downloads and says it sits in most agent harness dependency trees. It calls this the second LiteLLM incident of 2026, after the March TeamPCP campaign that hit versions 1.82.7 and 1.82.8.

How it works

The payload was a .pth file (the post calls it cook.pth). Python runs .pth files at interpreter startup, so the code executed without any import of LiteLLM. It collected cloud credentials, private keys, browser data and AI dev-tool auth files, then POSTed a tarball to an attacker endpoint. The post says .env files and browser profiles are exactly where it looked.

The entry point was the release pipeline. The attacker used stolen GitHub CLI OAuth tokens belonging to three engineers, pushed a trojanized commit chain through a lookalike repo, and built the official wheels and Docker images from it. Socket flagged the release 7 minutes after publication.

Preconditions / Affected

  • Anyone who installed or upgraded to litellm 1.107.0 during the roughly 100-minute window, including Docker images built from the official release.
  • Hosts where the Python process can read provider API keys, .env files, cloud credentials, SSH keys or browser profiles. The post stresses agent hosts, which hold provider keys in the environment, install packages on the same machine and import many packages at startup.
  • The post says a project pinned to litellm==1.76.1 was unaffected.

What to do

The post's checklist, in its own terms:

  1. Pin exact versions and content hashes. A hash-locked lockfile rejects an unexpected artifact.
  2. Issue one key per tool with a spend cap, so a stolen key has limited cost.
  3. Wait a day before adopting a new release. The post says a one-day cooling period would have avoided this incident entirely.
  4. Keep secrets out of places Python can read at startup, such as .env files and browser profiles.
  5. Monitor outbound traffic. An unexpected POST from a build box is the signal.

The post gives no commands. If you ran 1.107.0, the implied step is to treat every credential on that host as exposed and rotate it. The post does not state this.

Caveats

  • The post names no attacker endpoint, file hashes or other indicators, and no CVE or advisory ID.
  • It does not say whether the three engineers' tokens were rotated or how they were stolen.
  • The 1.76.1 anecdote is a second-hand report of one person's requirements file, not a general safe-version statement.

Technologies named here

Threat actors named here

Related in Supply Chain