If litellm 1.107.0 ever ran on a machine of yours, don't start with pip install: Python runs the implant on every start, pip included. LiteLLM's own incident report says 1.107.0 was on PyPI from 11:39 to 13:23 UTC on 21 Oct, and the docker tags latest, main-latest and main-stable pointed at an infected image until 14:20 UTC. The v1.107.0 git tag is clean. The payload was built from a lookalike repo. What to check: pip show litellm litellm-1.107.0.dist-info, cook.pth and sitecustomize.py in site-packages a detached python daemon holding /tmp/remote_code_loader.lock What to do: delete the three files first, kill the daemon, then reinstall pinned to 1.106.2 (or rebuild the venv or image). Not finding a file doesn't prove you're clean. Then rotate what the host could reach: the instance role, every provider key in the proxy DB, the master and virtual keys, the DATABASE_URL password, any secret in a process environment. In CloudTrail, look for GetCallerIdentity from the instance role around install time. What the stealer reads, per SafeDep's decode: SSH keys, cloud and CI credentials, AI tool tokens and the proxy's provider keys. docs.litellm.ai/blog/securit…