1-minute read
What a defender needs to know
Socket’s investigation found that the LiteLLM 1.107.0 image’s attached provenance recorded Berri-AI, with a hyphen, as source_owner instead of BerriAI. Three Python startup files in that recorded revision matched files in a poisoned PyPI wheel byte for byte. StepSecurity’s independent inspection found the files in affected container images too. BerriAI removed the release and infected images, according to StepSecurity; inspect running digests to establish what was actually deployed.
The wheel places cook.pth, cook.py and sitecustomize.py in site-packages. Python startup can launch a credential collector before an application imports LiteLLM. The collector sends encrypted results to hxxp://www[.]litellm[.]dev/healthcheck; the loader has a separate remote-code path. An empty loader pointer does not prevent collection.
Release owners should compare the expected source owner and commit with the recorded inputs of run 39587059944, then compare the published wheel and image contents with the approved tree. Reject mismatched release inputs before publishing. Operators should check litellm==1.107.0 and historical digests for GHCR’s litellm, litellm-database, litellm-non_root and Docker Hub’s litellm/litellm, including October 21 latest, main-latest and main-stable pulls. Preserve evidence; inspect archives from a clean environment, rebuild and rotate accessible credentials. Verify replacement digests and the absence of the three unexpected startup files in the rebuilt environment. Continue investigating historical egress and credential use for hosts that ran the poisoned release.