The .pth file that runs before your code: lessons from the LiteLLM 1.107.0 compromise
The .pth file that runs before your code: lessons from the LiteLLM 1.107.0 compromise Version 1.107.0 of the LiteLLM Python package was published with a credential stealer and a backdoor inside it. The package has been quarantined on PyPI and the malicious Docker images have been removed. The delivery mechanism is what makes this incident worth a closer reading rather than the payload list. A…
The .pth file that executes Python code before any application import presents a significant security risk, as demonstrated by the LiteLLM 1.107.0 compromise. This malicious package was published on PyPI and contained a credential stealer and a backdoor, which were delivered through three compromised GitHub engineer accounts. The compromised package had eight wheels and one source archive, the latter of which contained a tampered pyproject.toml file.
The first payload, named privcollect, stole various sensitive data such as cloud tokens, developer accounts, private keys, AI tooling credential JSON files, browser data, and LiteLLM deployment-specific credentials. This data was then sent to a malicious server. The second payload created a long-lasting background daemon that checked for updates from a GitHub repository every hour. If the repository became active again, the daemon would execute arbitrary Python code served by the attacker.
The malicious .pth file, containing the line "import cook", triggered the credential collector at interpreter start-up. Path configuration files like .pth files are processed by the site module during interpreter initialization, allowing them to launch malware without needing to be explicitly imported by your code. This mechanism can compromise any Python process using the infected environment, including scripts, scheduled jobs, or container images.
The attack used earlier LiteLLM compromises tied to the TeamPCP supply-chain campaign in March 2026, indicating that the same malicious delivery mechanism was employed. To mitigate the risk, it is crucial to check if the affected LiteLLM version was installed in any environment, compare wheel hashes instead of relying on version strings, and inspect .pth files in site-packages directories for any unexpected or malicious entries.
Revoking and replacing the compromised package from a clean machine is also recommended to prevent further exposure.
Written by urgent.news from Dev.to's reporting — not their text. Machine-written — may contain errors; check the original before relying on it.