SecureChap (@SecureChap) on X

What it is

A single X post from @SecureChap (no sources cited) claims that LiteLLM 1.107.0 on PyPI was malicious. The post says PyPI yanked the release the same day. It gives no date for the incident.

How it works

The post says attackers held stolen GitHub CLI OAuth tokens from three engineers. One token triggered the project-releaser workflow, and a second approved the run. That one job built eight malicious wheels and a tampered tarball, all after the compromise.

The wheels drop cook.pth, so import cook runs at every Python startup. The privcollect component collects cloud tokens, private keys, browser data, AI config files, environment variables and LiteLLM proxy credentials. It posts them as a zip to litellm[.]dev/healthcheck.

A second component installs a daemon. It polls github[.]com/letters9813/domain.txt every hour for new domains to fetch and execute.

Preconditions / Affected

Only litellm==1.107.0 is named. Any host or CI job that ran this install was exposed, because the .pth file executes on every interpreter start, not only when LiteLLM is imported.

What to do

The post names the vulnerable install command:

pip install litellm==1.107.0

Its stated mitigations are for maintainers:

• Use fine-grained OAuth tokens limited to a single repo.
• Require two-person approval on every release workflow.

The post gives no remediation steps for installed systems. Reasonable checks that follow from its indicators are to look for cook.pth in site-packages, and for traffic to litellm[.]dev or fetches of the letters9813/domain.txt path. Rotating the credential types listed above is also sensible. The post does not state any of these.

Caveats

The post is unsourced and offers no hashes, advisory link or wheel filenames. Check the claims against PyPI and LiteLLM maintainer statements before acting on them.