November 1: A compromised LiteLLM 1.107.0 release could steal credentials when Python started, even on a machine that never used the AI gateway. The release reached PyPI and official container images on October 21. Microsoft’s October 23 analysis gives teams a reason to revisit developer workstations, build agents and images now: an installed copy can leave startup files outside the package directory, and those files run again with the affected interpreter.
Microsoft observed a Windows Python process launched to install an unrelated dependency activate the collector. That ordinary maintenance action is the trap. Our earlier release coverage addresses the poisoned wheels; Microsoft adds endpoint-observed execution and the evidence needed to distinguish startup from completed upload. The analyst team writes that “starting Python in an affected environment could be enough.” LiteLLM gateway operators also face exposure of provider keys and proxy data, but the installed Python environment, rather than gateway traffic, defines the initial search area.
Startup files ran in affected environments
The poisoned wheel placed cook.pth, cook.py and sitecustomize.py under litellm-1.107.0.data/purelib/. Installation moved them into the environment’s library path, outside the litellm application folder. Python’s site documentation describes how interpreter startup processes executable lines in .pth files and later imports sitecustomize. A script importing an unrelated module can start the malicious components if it uses the affected environment.
In the first path, cook.pth loaded cook.py; the latter decoded an embedded collector and launched it in a daemon thread. The collector used the inherited PRIVCOLLECT_ACTIVE variable to limit duplicate work. In the second path, sitecustomize.py supplied a separate Unix-oriented loader. Deleting the litellm folder alone leaves the top-level startup files where Python can reach them. Short-lived processes may exit before a background collector finishes, so package installation and completed upload need separate evidence.
Collector reached local and cloud secrets
Microsoft’s recovered collector targeted AI-tool and source-control credentials, package-manager settings, cloud credential caches, Kubernetes service-account files, browser data, private keys and readable process environments. On proxy hosts, a conditional Prisma database module could query selected provider-credential and model-configuration fields, with a limit of 500 rows per query. Access depended on the process’s permissions and the module’s prerequisites; prioritize secrets reachable by that identity when scoping rotation.
The collector encrypted a collection document with AES-256-CBC, wrapped its key with RSA and packed the encrypted data for an HTTP POST to hxxp://www[.]litellm[.]dev/healthcheck. Microsoft saw Windows and macOS endpoint activity consistent with discovery, encryption and outbound connection. The staging prefix .pc_e_, the marker /tmp/.pc_once_72129118c59f5636c0bb attempted after an HTTP 200 response, and www[.]litellm[.]dev are correlation points alongside Python process ancestry. Microsoft lists these exact-file SHA-256 values for LF and CRLF startup-file variants:
cook.pth:7f191632e7320705d154b85204f1ae546b543acbd7e8861229b76f5042b92bdb,84dc8c82c0a4a4a62552ef826b49fcc86d1a5c4a5d0f2c06665723f93d129d7d.cook.py:9dd0a3926f96a37eb86cf1ee2310d9be93139cc4ebef3ef9e2efe9531390be25,03ac2a8b752605d1d7710979c17ff18b03dd978203ba23ba97fd8ce3d6f897ea.sitecustomize.py:34bef04fe88ac9d0aae0475630b1738681d15b94f233ac8aa46eacf5968305fa,b6122440d0d9cb1eb1ade9933f49214da8c31288de7710c076c2680dfa528465.
Unix loader offered another route
The sitecustomize.py path also prepared a background loader that could read a mutable GitHub-hosted pointer and retrieve additional Python code from a server it named. Microsoft describes this as a capability, while the pointer was empty when examined and second-stage retrieval and execution were unconfirmed. For triage, look for the loader’s /tmp/remote_code_loader.lock on Unix systems; GitHub hosting is shared infrastructure, so investigate the specific pointer and process activity rather than blocking the whole service.
Rebuild environments and rotate reachable keys
Inventory 1.107.0 in installed environments, pip and uv caches, mirrors, lock files, build outputs and container images. Compare immutable image digests and wheel hashes from Microsoft’s indicator list, especially where mutable tags were pulled during the release window. Isolate affected workstations, CI agents, test systems and gateway hosts. Inspect them from a known-clean system: running python or pip inside the suspect environment can trigger the startup hooks again.
Rebuild affected environments from verified artifacts, then check that cook.pth, cook.py and sitecustomize.py are gone from the environment library path. From a clean machine, rotate credentials that the affected identity could reach: model-provider and proxy keys, DATABASE_URL on proxy hosts, cloud and CI/CD credentials, source-control and registry tokens, private keys, AI-tool tokens and browser sessions. Revoke active identity sessions as part of that work. Correlate file hashes, process starts, .pc_e_ staging, destination connections and subsequent identity use before assessing what left a host.
A clean rebuild is useful only when the new interpreter starts without those startup files. Verify the rebuilt image digest and inspect its library path from outside the environment before returning its workloads to service; keep the credential rotation tied to the permissions the compromised processes held.