LiteLLM 1.82.7 and 1.82.8 shipped an infostealer: rotate everything those machines touched

Two releases of LiteLLM, versions 1.82.7 and 1.82.8, were published to PyPI carrying infostealer malware attributed by GitGuardian to a threat actor it calls TeamPCP ^[1][2]. PyPI maintainers pulled the packages quickly, but GitGuardian says the damage window was still significant, and its cybersecurity researcher Guillaume Valadon said LiteLLM "is downloaded millions of times a day, and it is highly likely that the blast radius is significant, despite PyPI's quick response in removing the malicious package" ^[3][4].

What the malware collected sets the scope of the cleanup. According to GitGuardian, it harvested SSH keys used to reach production servers, cloud credentials for AWS, Azure and GCP, Docker configurations, and information tied to crypto wallets ^[5]. That is not a list of things you monitor. It is a list of things you replace.

The detection guidance is worth running anyway. GitGuardian lists outbound connections from Python to scan.aquasecurtiy.org (45.148.10.212), checkmarx.zone (83.142.209.11), models.litellm.cloud and litellm.cloud as indicators, along with Python spawning curl, kubectl, find and xargs, or openssl ^[6][7]. Note that two of those hostnames are misspelled or off-brand lookalikes of security vendor names, which is a reasonable way to slip past an analyst skimming egress logs ^[8]. On disk, the checks are a backdoor at ~/.config/sysmon/sysmon.py, a user-level sysmon.service unit, and a litellm_init.pth file that GitGuardian says executes on Python startup ^[9]. A .pth file means the payload does not wait for anyone to import LiteLLM. There is also a Kubernetes check for worm pods whose names begin with node-setup- ^[10].

The important thing about that list is what a clean result proves, which is not much. None of those artifacts being present today rules out that a developer ran pip install once, shipped their key material, and the process exited. If a machine or a build runner installed 1.82.7 or 1.82.8, the credentials it held are burned, and the work is enumerating them: SSH keys, cloud access keys and roles, registry tokens, API keys in dotfiles and environment files, and anything those credentials could mint downstream.

Build systems are where this gets expensive. GitGuardian recommends auditing GitHub Actions, GitLab CI, CircleCI, Jenkins and similar automation for the two versions, checking requirements.txt, Pipfile and pyproject.toml, workflow configuration, container image definitions and Dockerfiles, and build and deployment scripts, with a manual review of every active branch and CI configuration ^[11][12]. Chainguard chief executive Dan Lorenc raised concern on LinkedIn about CI/CD systems in the context of this attack ^[13]. A pipeline credential typically has broader rights than a laptop credential and is rotated less often, which inverts the usual triage order.

Two caveats on sourcing. All of this comes from a single vendor account, published by a company that sells secrets detection, and GitGuardian says the same infostealer was used in the earlier Trivy campaign, which is its attribution rather than an independently confirmed link ^[14][15]. The report dates its own disclosure to a Tuesday without giving a calendar date ^[2].

What to watch: whether anyone publishes install counts for the two versions during the window, which would turn Valadon's estimate into a number; whether the sysmon persistence shows up on machines that never installed LiteLLM, which would indicate lateral movement; and whether the node-setup- pods appear in clusters, since that is the difference between a laptop cleanup and a production incident ^[3][9][10].