LiteLLM: check the artifact before your coding agent installs it

The clean tag and the compromised release

LiteLLM's maintainers report that all seven PyPI wheels for version 1.107.0 were compromised. Certain Docker Hub and GHCR container tags were affected too. The official GitHub source tag lacked the malicious files; the distributed artifacts came from an attacker-controlled repository. Their account names Berri-AI/litellm as the lookalike, distinct from BerriAI/litellm. Compare the complete repository identity, including its owner.^[1][2]

BleepingComputer and TechCrunch independently reported the incident, drawing on maintainer and security-company accounts. Those reports are corroborating coverage, not independent reproductions. The maintainer update, dated October 21 at 20:30 UTC, still describes an ongoing investigation. The lesson here concerns reviewing a proposed installation; this worksheet cannot diagnose an already affected host.^[1][2][5]

If an environment may already contain the affected release, do not use this exercise to investigate it by starting Python or pip. The advisory warns that Python startup can trigger the payload again. Use the incident-response guidance with your security team. A universal waiting period for every update would also ignore urgent vulnerability fixes.^[1][2]

Keep three questions separate

Origin asks where a file came from. Integrity asks whether the file matches the digest bound to its evidence. Safety asks whether its code and build environment deserve trust. PyPI's November 2024 attestation announcement describes verifiable links between files and publishing identities. Do not record a verified publisher as a verified build: evidence identifying the uploading workflow can leave the actual build inputs unresolved.^[3][4]

SLSA's May 2026 analysis of a separate npm compromise explains that cryptographically valid attestations coexisted with a compromised build environment. Expected repository and builder checks could pass there. Require authenticated evidence bound to the exact artifact, then compare its source, builder and declared inputs with expectations established independently of the proposed update. Matching everything still leaves code-safety questions.^[4]

Fill an acceptance record

Use these fields for each request: exact filename or container digest; expected and observed source; expected and observed builder; artifact-to-evidence digest binding; permitted build inputs; advisory status; unresolved checks; reviewer and disposition. Keep expected values separate from the agent's supplied values. Otherwise the proposal can define the very standard used to approve it.^[1][4]

Filled incident example: artifact, any LiteLLM 1.107.0 wheel; expected source, BerriAI/litellm; reported build source, attacker-controlled Berri-AI/litellm; expected process, the maintainer's qualified release workflow; reported process, a modified workflow accepting another repository. Advisory status: compromised. Disposition: reject this release. Wheel digest binding and any build-attestation verification remain unverified in this account; no attestation result is inferred from the source tag.^[1]

Predict four synthetic decisions

These are invented metadata cases for a static reading exercise, not additional incident findings. No package was downloaded, installed or executed for this article. Before reading the key, choose reject, hold, or eligible for further isolated review for each case. The proposed policy requires build evidence; absence alone does not establish malware.^[3][4]

A: authenticated build evidence names an unapproved lookalike repository; its subject digest matches the file. B: the attestation's subject is symbolic DIGEST-X; the actual file is DIGEST-Y. C: publisher identity is verified, but build provenance is missing. D: authenticated source, builder, digest and permitted parameters match expectations; no advisory is known, but code review is unfinished.^[1][4]

Compare your answer with the evidence

A: reject. Integrity does not repair an unapproved origin. B: reject the supplied evidence-artifact pair; evidence about another file cannot establish this file's provenance. C: hold pending build evidence under this proposed policy. A verified publishing step does not fill the missing build record. These decisions classify the supplied information, rather than proving maliciousness in every rejected or incomplete case.^[1][3][4]

D: eligible only for further isolated review and testing, with installation still unapproved. A compromised trusted environment or malicious intended source can defeat an origin-only decision. This exercise is not a benchmark or a tested prevention control. Save the completed record with its evidence and unresolved checks. An agent may organize the supplied public information; an accountable reviewer decides the next action.^[4]