Update Oct 25: Microsoft published Defender XDR advanced hunting queries (connections to www.litellm[.]dev, the six startup-file SHA-256 hashes, OpenSSL runs using .pc_e_ staging dirs, and an inline Python query against the LiteLLM_CredentialsTable/LiteLLM_ProxyModelTable tables) plus the marker file /tmp/.pc_once_72129118c59f5636c0bb, written after a successful upload. Investigate from a clean machine: running python or pip in the affected environment can set off the collector. On the GitHub side, LiteLLM's root-cause analysis lists IPs 69.48.229.143 and 199.91.221.39, the lookalike org Berri-AI, and branches named like ci-tmp-* whose workflows posted secrets to webhook.site. If your org was forked by or interacted with these, check your own audit log.

For the LiteLLM 1.107.0 compromise:

1. Files: any site-packages/cook.pth, cook.py or an unexpected sitecustomize.py (plus their __pycache__ copies), in venvs, containers and CI caches. cook.pth contains only import cook.
2. Markers: /tmp/.pc_once_72129118c59f5636c0bb, /tmp/remote_code_loader.lock, /tmp/.pc_sq_*, /tmp/.pc_e_*.
3. Processes: detached Python processes started via setsid with working directory /, or holding the loader lock.
4. Network: DNS or proxy hits for www.litellm[.]dev / litellm[.]dev (POST /healthcheck, header X-Token: XWiA8gZNa7NcX2XRoAEb, old IE user agent), hourly requests to raw.githubusercontent[.]com/letters9813/pythonclient-test/main/domain.txt, then http://<domain>/codepy. Also look for reads of 169.254.169.254 from Python on hosts that shouldn't need it.
5. CI: any runner job that installed litellm 1.107.0 or ran its image: StepSecurity notes the stealer reads /proc/<pid>/environ of every process, so treat every secret in that job as stolen.

Clean up with tools that don't start the affected interpreter, preserve proxy/DNS/EDR and cloud audit logs first, then rotate.