LiteLLM 1.107.0 compromise puts AI gateway credentials at risk

[JFrog's October 21 analysis](https://research.jfrog.com/post/litellm‑hijacked‑again/) identifies malicious files in the seven platform wheels for LiteLLM 1.107.0, a Python interface and proxy used to route requests to language models. The files execute through Python startup mechanisms, so the application does not have to import LiteLLM for the payload to run. JFrog also reports an affected official container image. The research describes credential collection and a remote‑code loader. It says the source archive lacks the executable payload files present in the wheels. That gap makes a repository review insufficient: the release artifact installed on a developer machine or gateway is the relevant object. JFrog reports removal of the PyPI release and affected image tags. Removal limits new downloads but cannot recall existing images, cached wheels or running processes.

[Socket's independent investigation](https://socket.dev/blog/litellm‑compromise) reports that floating tags, including latest, main‑latest and main‑stable, resolved to the affected image during its investigation. Teams that never explicitly requested version 1.107.0 should therefore inspect their actual deployment history. Record the image digest or wheel hash, where it was cached, when it was deployed and which identities it could access. A tag name can change after a pull; a current registry listing cannot establish what ran earlier. Scope CI workers, developer environments and proxy containers separately. The reports describe collection extending beyond model‑provider keys to cloud identities, private keys and development‑tool authentication material. The response should follow the environment's reachable secrets, rather than being limited to the LiteLLM API configuration.

Socket says the container's attached provenance names a hyphenated source owner, Berri‑AI, where legitimate releases reference BerriAI. [Upwind's report on the project tracker](https://github.com/BerriAI/litellm/issues/47826) supplies matching public artifact evidence. This points investigators toward the release‑input boundary, but does not establish which person, credential or system first allowed the alteration. JFrog explicitly distinguishes the new payload and infrastructure from the earlier March LiteLLM compromise and says the exact publishing breach remains unknown. Attributing this incident to the earlier campaign would go beyond that evidence. The practical lesson is to bind a release to both its reviewed source and final artifact. A signed commit or valid package name alone cannot prove that the wheel and container contain only the reviewed files.

Upwind warns that starting Python in an affected environment can execute the startup hooks again; that includes using its pip command to investigate or downgrade. Teams should isolate the environment, preserve relevant evidence and use trusted tools outside it for response. The researchers favor rebuilding virtual environments and images rather than relying on an in‑place package replacement. Revoke or rotate secrets that the compromised process could reach, from a clean system. Review provider and cloud activity for unexpected use, including identities held in the gateway database or inherited from its host. Absence of a local marker is not reliable clearance when containers or temporary files may have been removed. An [earlier Upwind issue update](https://github.com/BerriAI/litellm/issues/47826) recorded affected floating tags still present, while JFrog later reports removal. Treat the status as time‑sensitive and verify the exact artifact before redeployment. OpenTools has not run the malware or independently certified a replacement release.

The next substantive update should come from the maintainers and registries: a verified release timeline, the initial access explanation, affected artifact identities, revoked publishing credentials and an independently checkable clean rebuild. Those facts will determine how confidently teams can restore normal automated updates. For AI infrastructure owners, the incident highlights a concentrated trust boundary. A gateway can hold keys for many providers and workloads, so its build pipeline and service identity deserve the same scrutiny as a secrets service. Pinning an artifact helps make deployments reproducible; the pinned artifact still needs verification. *Figure by OpenTools Team; no third‑party expressive material used. Original explanatory figure, based on the linked artifact investigations. No malware was downloaded or executed to prepare this report.* Related: [How agent access can reach live personal and confidential data](https://opentools.ai/news/india‑cert‑in‑ai‑agents‑live‑systems‑personal‑data).