LiteLLM 1.107.0 supply-chain compromise: how to find affected copies on AWS, rebuild clean and rotate cloud and LLM keys

LiteLLM is a Python SDK and proxy that sits between applications and LLM providers. LiteLLM's incident post lists the affected artifacts: all seven litellm==1.107.0 wheels on PyPI, and the four Docker Hub and GHCR tags above. On Docker Hub, the tags pointed to the compromised image index sha256:1bbcb1443bc962e45f5aad53fe3d2c30600e0379715fb6c664cdd3ac126c339e. The post lists separate digests for the litellm-database and litellm-non_root images on GHCR. Check the post for those. The artifacts have since been removed from PyPI, Docker Hub and GHCR.

LiteLLM's attack-chain report, published on 23 October 2026, explains the root cause. An administrative key for an internal, experimental LiteLLM Agent Platform had been committed to a public repository and was still valid more than four months later. On 10 October 2026, the attacker used it to extract a GitHub organization owner's GitHub CLI OAuth token. That token was then used to change the release workflow so it built from the lookalike fork.

GitHub issue 47826 notes that the reporters "did not inspect the v1.107.0 Docker images", and CERT-In describes them as "reportedly compromised". Treat any container that ran the compromised digest as affected.

Python processes .pth files and tries to import sitecustomize while the interpreter starts. cook.pth contains import cook, so the stealer runs on every Python start in that environment. That includes CI agents, test machines, notebooks and unrelated Python applications. It also includes running pip install or pip show inside the suspect environment. Microsoft Security Research, in its analysis of 23 October 2026, says investigators "should not start Python or pip inside a suspect environment".

The files sit outside the litellm package directory, so removing the package or the image tag is not enough. Microsoft says removing the package or a release tag "is not sufficient recovery".

The second component, sitecustomize.py, starts a background loader on Unix-based systems. It reads an attacker-controlled file on GitHub every hour and can download and run Python code. Microsoft reports that the file was empty when researchers checked it, and that no second-stage retrieval was confirmed. Because the file can be changed, the loader can be re-armed.

1. Lockfiles and manifests. Search requirements.txt, poetry.lock, pyproject.toml and other manifests for litellm==1.107.0. Also check build logs for unpinned litellm installs on 21 October 2026.
2. Container images. Compare image digests in your Amazon ECR repositories, Amazon ECS task definitions and Kubernetes pod specs against the compromised index digest. Look for the latest, main-latest, main-stable and v1.107.0 tags pulled during the window. Amazon ECR enhanced scanning, which uses Amazon Inspector, scans images for both operating system and programming language package vulnerabilities. Basic scanning covers operating system packages only. We found no AWS statement that these scans flag LiteLLM 1.107.0, so compare digests directly.
3. Software inventory. Amazon Inspector can export an SBOM, in CycloneDX 1.4 or SPDX 2.3 format, for the EC2 instances, ECR images and Lambda functions it monitors. Search the export for litellm version 1.107.0. A clean SBOM is not proof on its own, because it covers only resources Inspector actively monitors.
4. Mirrors and caches. Check AWS CodeArtifact or any other internal PyPI proxy, plus pip and uv caches on build agents.
5. File evidence, checked from outside the environment. Look for cook.pth, cook.py, sitecustomize.py, litellm-1.107.0.dist-info, /tmp/remote_code_loader.lock and /tmp/.pc_once_72129118c59f5636c0bb. LiteLLM's post says finding one confirms exposure, but not finding one does not prove the environment is clean. GitHub issue 47826 says the marker file is written only after a successful exfiltration upload, and LiteLLM's post says container and temporary-file cleanup removes it.

The OSV record MAL-2026-2144 lists 1.107.0 as malicious. Its indicators can feed your own searches.

• Isolate first. CERT-In asks teams to isolate suspected hosts and containers, "preserving relevant logs and forensic evidence before making changes".
• Investigate from a known-clean machine. Use trusted tools from outside the environment, and do not run Python or pip inside it.
• Rebuild, don't clean in place. CERT-In asks teams to rebuild or redeploy containers from a verified clean image and not to rely solely on in-place cleanup. LiteLLM's post says rebuilding images and virtual environments from scratch is better than deleting files.
• Pin what you rebuild. Pin LiteLLM by version and hash, and pin container images by digest, not by tag.
• Purge the bad artifacts. Remove 1.107.0 and the compromised images from local caches, internal mirrors and container registries.

On the version to reinstall, CERT-In's advisory says: "The supplied analysis identifies 1.106.2 as a clean version; verify its integrity and suitability before pinning it." LiteLLM's incident post also asks users to pin 1.106.2. As of 30 October 2026, PyPI lists later releases, 1.106.3 to 1.106.6, published between 24 and 28 October 2026. CERT-In's advisory does not name them. Separately, LiteLLM's GitHub security advisory GHSA-w4c7-34wj-hqm8, published on 27 October 2026 (UTC), rates a flaw on proxies running with an Enterprise license as critical and lists 1.106.5 as the patched version in the 1.106 line. It says open source deployments without a license are not affected. Check LiteLLM's current guidance before choosing one.

Do every rotation from a trusted machine, never from an affected host. Microsoft advises revoking sessions rather than assuming that rotating a key invalidates every active token.

Rotate LLM provider keys even if their usage looks normal. On proxy hosts, the collector targeted the database tables that store them.

• CloudTrail Event history. Look up events by the AWS access key attribute, or by user name. Event history covers management events in a Region for the last 90 days.
• The role's own trail. LiteLLM advises checking CloudTrail "for GetCallerIdentity from the instance role around install time, then for use of the role's credentials from outside your infrastructure." The GitHub issue notes that the stealer validates stolen role credentials with STS GetCallerIdentity.
• GuardDuty. The UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS finding reports EC2 instance credentials used from an external IP address. UnauthorizedAccess:IAMUser/ResourceCredentialExfiltration.OutsideAWS covers credentials from a Lambda function or ECS task. These findings flag credential misuse. They do not identify LiteLLM.
• Network logs. Search DNS, proxy, firewall, container and CI/CD logs for www(.)litellm(.)dev, requests to /codepy, and reads of the GitHub repository letters9813/pythonclient-test.
• The proxy itself. Review LiteLLM proxy database access and upstream provider usage for unexpected calls.

The CERT-In Directions of 28 April 2022, issued under section 70B(6) of the IT Act, say service providers, intermediaries, data centres, body corporate and Government organisations "shall mandatorily report cyber incidents as mentioned in Annexure I to CERT-In within 6 hours of noticing such incidents". Annexure I lists, among others, "Malicious code attacks", "Unauthorised access of IT systems/data", "Data Breach", "Data Leak", and attacks or suspicious activity affecting cloud computing systems and AI and machine learning systems.

Whether your exposure is reportable depends on what ran and what was taken. Ask your CISO or legal team. For the AWS side, see our guides on CERT-In log retention and 6-hour reporting on AWS and on DPDP breach reporting on AWS.

• Use hash-pinned lockfiles, verify package and image provenance, and deploy images by digest rather than floating tags.
• Admit packages to internal mirrors only after review. CodeArtifact package origin controls protect against dependency substitution, but they don't stop a malicious version from a legitimate upstream, so keep pinning.
• Restrict outbound internet access from build agents and AI gateway hosts to what they need.
• Give gateway hosts least-privilege, short-lived identities. Our guide on hardening AWS secrets and IAM after CIAD-2026-0049 covers this.

Upvantix is an AWS Select Tier Services Partner. After you have contained the incident, a security posture assessment can help. We review architecture and controls, then prioritize material remediation actions. Our AWS Security & Cost Optimization work also includes identity, network and data-control assessment; configuration, logging and detection review; a risk-ranked remediation and optimization backlog; and approved implementation and validation. AWS Security Hub, Amazon GuardDuty, Amazon Inspector, AWS Config, AWS IAM Access Analyzer and AWS KMS may be used where appropriate. This is a posture review, not an incident-response or forensics service, and we do not give legal advice on reporting.

Talk to us about an AWS security posture review after the LiteLLM incident.