Security response · October 2026
LiteLLM 1.107.0 compromise exposure and recovery checklist
Start with installation and deployment history. The decision tables below separate artifact exposure, environment recovery, and credential response, including checks that must be performed outside the suspect Python environment.
Incident guidance can change. Use the linked vendor notices for current scope and instructions.
Quick answer
For the LiteLLM 1.107.0 compromise, establish which wheel or image reached each environment and whether it executed. Use trusted external records or offline inspection. A current clean version or source tag cannot settle historical artifact exposure, and Python or pip inside the suspect environment can retrigger malicious startup files.
What was compromised
LiteLLM's 21 October incident report identifies malicious release 1.107.0 artifacts on PyPI and container registries, including moving tags. The official source tag did not contain the malicious files, so source inspection alone does not establish which artifact ran. Its private enterprise registry was outside the stated impact. LiteLLM incident report.
| Evidence to inspect | Incident detail to match |
|---|---|
| Package/build history | PyPI release 1.107.0; vendor window approximately 11:39–13:23 UTC on 21 October |
| Container pull and deployment records | Affected v1.107.0, latest, main-latest, and main-stable artifacts |
| Container identity | Exact registry and digest; use the vendor's registry-specific list |
| Source-only record | Insufficient to identify the wheel or image installed |
The vendor lists Docker Hub and GHCR exposure windows separately. Preserve the artifact identity and time rather than assume today's tag resolves to what ran yesterday. Confirmed affected artifacts.
Why can a version check be unsafe
Datadog's original analysis describes malicious Python startup files, including cook.pth and sitecustomize.py. Those can run on interpreter startup; invoking pip can retrigger the code. Deleting only the LiteLLM package directory does not remove all of those files. Datadog Security Labs analysis.
Use retained build manifests, lockfiles, registry records, image inventories, or an incident responder's offline inspection. Do not import LiteLLM as a diagnostic. The purpose of triage is to learn what executed without executing the suspect environment again.
What does each exposure finding mean
| Finding | Working classification | Next step |
|---|---|---|
| Affected artifact ran in a service, runner, or developer environment | Treat the environment as compromised | Isolate, preserve evidence, investigate reachable credentials, rebuild |
| Affected artifact is cached or present, execution history uncertain | Unresolved exposure | Prevent execution and investigate records through trusted tooling |
| Current version is clean, historical records show an affected deployment | Historical exposure remains open | Investigate the earlier environment and its credentials |
| Records show the affected artifact never reached the environment | Evidence supports no exposure through this release for that environment | Keep the records and their time/coverage limits |
| No records survive | Unknown | Escalate the uncertainty rather than label it clean |
This is an operational decision aid. It does not replace the vendor's affected-artifact list or an incident investigation.
Three false assurances during LiteLLM triage
| Observation | What it leaves unresolved | Better evidence |
|---|---|---|
| The repository tag looks clean | The release artifact may have been built from different source | Installed artifact identity and registry records |
| The service now uses a different version | An earlier environment may already have executed the affected artifact | Historical build, pull, and execution records |
| The package directory was removed | Startup files or credential exposure can remain | Environment recovery and identity investigation |
The source/artifact distinction is documented by LiteLLM; the startup behavior is described in Datadog's original analysis.
How should recovery proceed
Assign two linked workstreams: environment recovery and identity recovery. Keep them coordinated so that replacement secrets are not delivered to a host that is still suspect.
For the environment:
- Isolate it through trusted infrastructure controls and pause jobs that could execute the suspect interpreter.
- Preserve the artifact identities, build/deployment history, and relevant evidence before replacing the environment.
- Identify other environments that reused the same image, virtual environment, runner cache, or build output.
- Rebuild through a trusted path using a version and artifact approved by the current vendor guidance.
- Validate the replacement and prevent deployment of the identified affected artifacts.
For identities:
- Inventory what the suspect environment could reach, including mounted secrets and delegated identities.
- Have each credential owner revoke or rotate affected authority from a clean administrative environment.
- Check for unexpected activity, newly created access, and changes during the relevant period.
- Give replacement credentials only to the recovered consumers and verify their operation.
Datadog's analysis identifies cloud, developer, browser, AI-tool, and proxy credentials among the payload's targets. Its recovery guidance calls for rotation from a clean machine and review of credential use. That is why replacing only the model-provider key can leave other access unresolved. Research and recovery guidance.
What should the recovery handover include
Use one record for each environment:
- Owner, environment, and isolation time:
- Artifact registry, version, and digest:
- Earliest known installation and execution:
- Evidence preserved and retention limits:
- Credentials and delegated identities reachable:
- Revocation and replacement evidence:
- Related caches, images, runners, and developer systems reviewed:
- Trusted replacement deployment and validation:
- Remaining investigation and next owner:
Treat missing indicators carefully. LiteLLM warns that not finding a marker does not prove the environment is clean. Its response section also warns against starting with pip inside the affected environment. Vendor recovery guidance.
Can a website scan confirm recovery
A public URL scan cannot see every Python startup file, runner cache, delegated identity, or provider audit record. Recovery needs environment and identity evidence. Once that work is complete, an external scan can help assess the public application as an additional layer. How to choose security evidence.
Questions gateway operators ask
Is a clean dependency file enough to rule out exposure
No. Match historical installed artifacts and running images to the incident list. A clean current lockfile describes one state of the project; it does not reconstruct earlier runner, container, or developer environments.
Should I run pip show to check the affected installation
Use trusted records or offline inspection first. The malicious startup behavior means invoking the suspect environment's Python or pip can execute code again. Preserve and inspect that environment through an incident response process.
Cite this guide
Vibe App Scanner. “LiteLLM 1.107.0 compromise exposure and recovery checklist.” Technical sources reviewed 22 October 2026. Artifact details come from the linked vendor report and original researcher analysis; the decision table is VAS editorial guidance.