Response to the affected LiteLLM release

By October 27, 2026, the Roundtable had evidence that LiteLLM 1.107.0 contained the payload across all seven platform wheels and that Python startup mechanisms could execute it after installation or container startup.

That evidence supports immediate triage based on installation and runtime history: confirmed or unexcluded execution requires incident response, while verified cache-only possession does not.

Exact hashes and immutable image manifest digests remain unavailable in this packet, but that enrichment gap does not prevent version blocking, workload isolation, evidence preservation, clean rebuilding, or rotation of credentials reachable by an executed workload.

Four groups require distinct treatment.

First, developers, CI runners, build hosts, servers, or other Python environments where LiteLLM 1.107.0 reached site-packages may have executed its startup hooks during any Python launch, including pip.

Second, container operators whose affected image started must treat the workload as potentially executed and assess every identity, mount, secret, and service it could reach.

Third, maintainers of package caches, container registries, or image caches that only stored LiteLLM 1.107.0 may use the cache-only path if telemetry proves no installation or startup: quarantine and purge the artifact before reuse.

Fourth, operators without reliable installation and runtime history must treat execution as possible and apply the full incident-response path.

Potentially exposed credential owners include teams responsible for cloud, AI-provider, database, SSH, and application credentials reachable by an executed workload.

1. Support: The malware reverser's October 27, 2026 analysis reports that LiteLLM 1.107.0 carried the payload in all seven platform wheels and distinguishes execution against poisoned site-packages from mere artifact possession.
2. Support: The defense architect's October 27, 2026 analysis identifies installation into site-packages or startup of an affected container as the minimum go/no-go evidence. It states that any Python launch, including pip, could trigger startup hooks and supports isolation, evidence preservation, clean rebuilding, use of LiteLLM 1.106.2 or another verified-safe artifact, and rotation of reachable credentials.
3. Support: The Roundtable synthesis states that executing LiteLLM 1.107.0 warrants incident response.
4. Support: The evidence audit finds consistent backing for the execution-or-missing-history threshold, the recovery actions, and the cache-only exception after quarantine and purge.
5. Evidence gap, not contradiction: A separate audit finds that the evidence identifies LiteLLM 1.107.0 and supports blocking by hash or immutable image digest but does not supply the exact verified identifiers needed for a precise blocklist.

The decision scout identified an operational split between possession and execution of LiteLLM 1.107.0.

The malware reverser reported that the payload was present in all seven platform wheels but set the compromise boundary at Python execution against the poisoned site-packages, not mere possession.

The defense architect translated that boundary into a test: determine whether LiteLLM 1.107.0 reached site-packages or an affected container started, treating missing runtime history as possible execution.

The key uncertainty—whether cache possession alone required full incident response—was resolved with a bounded exception for verified cache-only exposure after quarantine and purge.

The evidence auditors supported the execution threshold and recovery steps while identifying the absence of exact wheel hashes and immutable image manifest digests.

The boundary review found the guidance suitable for public use if it refers only to verified digests and does not imply those identifiers are supplied.

The linker found no prior matching record, and the arbiter selected a new operational record because the identifier gap did not undermine the incident threshold or recovery actions.