Cleanup can look complete at the host level while an exposed service, cached artifact, or stale credential remains in place. The LiteLLM 1.107.0 response needs a baseline that survives the first rebuild. It should show which services are visible, who owns them, which artifacts they run, and whether the evidence supports closure.
LiteLLM's incident report gives a clear recovery direction: remove the compromised artifacts from registries, rebuild affected containers and environments, rotate credentials, and verify that old releases cannot return through caches. A one-time scan is useful for discovery but weak as evidence of a stable state.
Separate the two baselines
The external baseline answers where LiteLLM services are visible. On November 1, ZoomEye returned 65,958 matches for title="LiteLLM" and 5,145 for title="LiteLLM" && port="4000". The first is a broad title population. The second is a narrower service view that aligns with the documented default proxy port.
The internal baseline answers which deployments exist and what they run. It should include package names and versions, image digests, deployment owners, environments, and ingress policy. The external count can reveal a service missing from this record. The internal record explains whether the visible service is expected and whether it used an affected artifact.
These baselines should be joined at the owned asset level, not by adding counts together. One host can appear in multiple queries. One owner can operate several gateways. One gateway can run behind a load balancer with several addresses.
Define closure evidence
A service is ready to close only when the team has identified its owner and artifact, verified that the compromised release is not installed or cached, and confirmed that the current authentication and ingress configuration match policy. If the service could have executed the payload, closure also needs a credential-rotation record and a check for persistence or follow-on activity.
The evidence should include timestamps. A clean scan executed before a replacement image was deployed does not prove the final state. A new key created from a suspect environment does not prove rotation. A removed public tag does not prove that every internal mirror and container cache is clean.
CERT-In recommends checking package manifests, site-packages, process and network logs, proxy database access, provider usage, and cloud audit trails. Those checks form a useful closure matrix because they cover the artifact, the runtime, and the downstream identities.
Watch for count drift and ownership drift
Repeating the same ZoomEye query after cleanup provides a comparable observation only when the scope and field remain the same. Record the time and total. Investigate a material change rather than assuming that a lower count proves remediation. A title can disappear because a service was retired, a page changed, or scan coverage shifted.
The owned list is the more reliable control. Add the owner and environment to each confirmed service. Set a review date for any public gateway that has no owner. Track new appearances of the default port and changes to administrative exposure. A stable total with unresolved ownership is not a stable control.
Keep artifact control after the incident
Pin a verified LiteLLM release and store the digest or package hash used to build each image. Remove mutable tags from production deployment paths where policy permits. Keep the package mirror and container registry records in scope, because an old artifact can be reintroduced by a build that resolves a name rather than a verified object.
Review the release workflow as part of the same baseline. The LiteLLM attack chain involved a stolen GitHub token, a source-owner input, and a release approval. Teams should confirm that their own builds cannot redirect to an arbitrary repository and that the identity approving a release cannot also rewrite the protected branch.
Make monitoring answer a decision
The next review should answer four questions: Is the service still visible? Does an owner claim it? Which artifact does it run? Has the credential and log evidence changed? Those questions produce actionable outcomes. A raw LiteLLM count without them becomes a number that teams cannot defend.
ZoomEye's role is to keep the external view current and auditable. Internal deployment, artifact, and identity records provide the closure proof. The incident is contained only when both views converge on the same owned services and the evidence behind each decision is retained.