LiteLLM users should check the artifact they installed, not just the repository they reviewed. JFrog's October 21 investigation identifies malicious code in all seven Python wheels for version 1.107.0 and the corresponding official Docker image. Python startup can activate credential theft without importing LiteLLM.

What is confirmed—and what is not

JFrog reports that the source archive lacks the wheel's executable payload files. Mutable container tags also exposed systems while they pointed to the compromised image. The payload targets developer, cloud, and AI-provider secrets, including credentials stored by LiteLLM proxies. An hourly loader can retrieve additional code. JFrog does not establish the precise publishing compromise or attribute this incident to the March attackers.

An independent researcher's October 21 issue in the project repository corroborates the seven malicious wheels and startup hooks. Its update reports removal of the PyPI release and affected container tags. Removal prevents some new exposure; it does not repair existing installations. Treat the issue as researcher reporting, not a blanket vendor assurance that every deployment is safe.

Response priorities

  1. Scope from outside the suspect environment. Identify installed versions, cached wheels, build records, and container digests. The researcher provides per-wheel hashes. Do not start the affected Python interpreter or run its pip for initial triage: startup hooks can execute again.
  2. Isolate and preserve. JFrog recommends isolating affected hosts and containers and rebuilding from verified artifacts. Preserve evidence before replacing them. Its report provides startup-file and detached-process investigation details.
  3. Recover credentials separately. Rotate secrets reachable from the affected environment using a clean administrative system. JFrog explicitly includes upstream provider credentials stored in the proxy. Rebuilding alone cannot revoke credentials already copied.
  4. Track downstream use. Review cloud, source-control, package-registry, and AI-provider activity against the exposure window. Record confirmed misuse separately from possible exposure.

Bulwark assessment

For SMBs and government contractors, assign two recovery owners: one for trusted systems and one for credentials and downstream accounts. Require evidence for both before closing the incident. A working application is not proof of a trustworthy environment, and a clean source tree is not proof of a clean wheel.

For future builds, retain exact artifact digests and installation provenance alongside dependency inventories. That gives a lean response team a concrete exposure list instead of a company-wide search based only on product names.