LiteLLM says attackers hijacked its release pipeline on October 21 and published a malicious version 1.107.0 to PyPI and Docker. It steals credentials and loads remote-code tools. LiteLLM says no earlier version is affected by this incident (1.82.7 and 1.82.8 were compromised in a separate attack earlier this year); enterprise private-registry customers were not affected.
LiteLLM says version 1.107.0 of its open-source Python package and Docker images was malicious, after attackers hijacked its release pipeline on October 21. According to LiteLLM, the release "contained compiled malware which steals credentials and loads remote-code execution tools." LiteLLM says earlier versions are not affected by this incident, and the bad files have been pulled from PyPI, Docker Hub and GHCR. (Versions 1.82.7 and 1.82.8 were compromised in a separate incident earlier this year and should also be avoided.) LiteLLM, Datadog and Wiz recommend pinning to 1.106.2. All times below are UTC on October 21, 2026.
What happened, in plain terms. LiteLLM is a popular open-source tool that lets developers connect apps to many AI models through one interface. For about two and a half hours, official downloads were swapped for a version that steals passwords and access keys from the machine it runs on and lets attackers run more code later. If you don't run LiteLLM yourself, you don't need to do anything. If your company or a developer you work with uses it, forward this to them.
Who's affected. You are affected if any of these is true:
litellm from PyPI between 11:39:51 and about 13:23 UTC, or any environment ever started Python with 1.107.0 installed.v1.107.0, latest, main-latest or main-stable from Docker Hub between 11:46:56 and 14:20 UTC, or from GHCR from 11:46:56 UTC until the tags were made unavailable by 13:51 UTC.Times are LiteLLM's. Wiz and Datadog put the PyPI quarantine at 13:20 UTC and Docker image removal at about 13:53 UTC, but LiteLLM says its Docker Hub tags still pointed to the malicious image at 13:51 and weren't fully cleaned up until 14:20, so use the longer window.
Enterprise customers pulling from LiteLLM's private registry were not affected, LiteLLM says. Checking only source code won't catch it: the source tarball and the official GitHub v1.107.0 tag don't contain the payload files, according to JFrog.
Key terms.
latest is a label that can move to a new image; a digest (sha256:…) is a fingerprint of one exact image.Check whether you were hit. For technical readers. Run these from the shell, not through Python.
pip show litellm, but pip is Python and would re-run the payload.find / \( -name 'litellm-1.107.0.dist-info' -o -name 'cook.pth' -o -name 'cook.py' -o -name 'sitecustomize.py' \) 2>/dev/null
find / -path '*site-packages*' -name 'litellm-*.dist-info' 2>/dev/nullAccording to LiteLLM, finding litellm-1.107.0.dist-info, cook.pth or sitecustomize.py confirms exposure. Not finding them does not prove the system is clean.
/tmp/.pc_once_72129118c59f5636c0bb as a marker file. LiteLLM says, "If the marker file exists, the exfil is confirmed." If it is missing, LiteLLM says "that proves nothing: containers and tmp cleanup remove it".ls /tmp/.pc_once_72129118c59f5636c0bb 2>/dev/nullls -l /tmp/remote_code_loader.lock 2>/dev/null
fuser -v /tmp/remote_code_loader.lock 2>/dev/null || lsof /tmp/remote_code_loader.lockdocker images --digests | grep litellm
docker inspect --format '{{json .RepoDigests}}' <image>Treat any container that ran one of these digests as compromised:
litellm: sha256:1bbcb1443bc962e45f5aad53fe3d2c30600e0379715fb6c664cdd3ac126c339e.ghcr.io/berriai/litellm: sha256:1bbcb1443bc9… (LiteLLM publishes only this prefix; it matches the Docker Hub digest).ghcr.io/berriai/litellm-database: sha256:c00f9d92c427…ghcr.io/berriai/litellm-non_root: sha256:7b00e91cd2fe…Clean up. These are LiteLLM's steps, which it credits to researcher LidorMachluf. Don't start with pip install: any Python start runs cook.pth and sitecustomize.py again, and that includes pip.
cook.pth, cook.py and sitecustomize.py, plus any __pycache__/cook*.pyc and sitecustomize*.pyc, from every affected site-packages directory./tmp/remote_code_loader.lock.litellm==1.106.2. LiteLLM says rebuilding images and virtualenvs from scratch is better.latest, main-latest or main-stable. Pinning by digest (image@sha256:…) after you check it is a common hardening step; LiteLLM's post doesn't specifically recommend it.Rotate credentials. LiteLLM says that if 1.107.0 was ever installed on a host with outbound internet access, assume the theft worked. Datadog Security Labs recommends rotating from a clean machine. Rotate everything the host could reach, especially:
DATABASE_URL passwordThe stealer also goes after cloud, developer, browser and AI-tool credentials, according to Datadog and Wiz. LiteLLM also suggests checking CloudTrail for GetCallerIdentity calls from the instance role around install time, then for use of that role's credentials from outside your infrastructure.
How the attackers got in. According to LiteLLM, the attacker had three sets of stolen developer GitHub CLI credentials. One, belonging to a GitHub organization owner, was used to override branch protection on LiteLLM's private release workflow. A second was used to pass the production approval gate at 11:11:18 UTC. The attacker pointed the workflow at a lookalike repository, Berri-AI/litellm instead of BerriAI/litellm, and that run signed and published the poisoned files. A third account's credentials were used to delete the workflow records.
LiteLLM believes the tokens came from the logs of an internal LiteLLM deployment exposed to the internet. It says it has observed Claude Code, in specific situations, embedding a user's GitHub CLI OAuth token in a response body, and logged response bodies can end up in LiteLLM logs. LiteLLM hasn't confirmed how the attacker got into that deployment but suspects a recently patched vulnerability.
Second incident this year. This is the second LiteLLM supply-chain compromise this year, after versions 1.82.7 and 1.82.8, according to Datadog. LiteLLM and OX Security place the earlier incident in March. Datadog says no link between the two has been established.
What's next. LiteLLM now labels the incident 'contained, investigation in progress.' It promised updates every two hours, but its post was last updated at 20:30 UTC on October 21; the update promised for 22:30 UTC had not appeared as of 12:25 UTC on October 22. Community tracking is in GitHub issue #47826.
Tap a lens to see what this story means for you.
Liked this? The Brief brings you the whole day in tech, verified, every morning.
Two minutes, free forever. What's in The Brief →
See what’s happening right now
The Feed runs all day — short, verified briefs the moment they break.
Open the FeedFollow @thecircuitry_
Every story we publish, as it happens. No noise between.
Reader-supported
The Circuitry is a passion project I've always wanted to build, and I love the work behind it.
Running it costs real money. APIs, hosting, time. To keep improving the site and growing this into something useful for everyone, those costs have to be covered.
Any contribution is appreciated. If not, no pressure. Thanks for reading.
ADT and Thrive Holdings announced an all-cash deal that values ADT at about $7.6 billion in equity value and $15.3 billion in enterprise value, according to the companies. ADT stockholders would get $10.00 per share, and the companies expect the deal to close in the first quarter of 2027, pending stockholder and US antitrust approval.
CISA says it added Linux kernel flaw CVE-2026-46300 to its Known Exploited Vulnerabilities catalog on Oct. 28, with a federal deadline of Oct. 31 and forensic triage required. CISA says it can be chained with two PHP flaws to implant webshells and run commands as root.
CISA says it added CVE-2026-41709, an insufficient logging flaw in Broadcom's VMware ESX, to its Known Exploited Vulnerabilities catalog on Oct. 28. The flaw requires admin access, and CISA lists a Nov. 11 federal deadline; it has not said who is exploiting it.
Sony Network Communications, the wholly owned Sony Group company behind the So-net internet service provider, says a third party accessed its So-net member database on Oct 19 and that up to about 2.6 million member records leaked, including 443,495 from plala (S Course) and 16 bank-account records. No credit card data leaked, Sony says.
Microsoft published CVE-2026-62765 on Oct. 27, describing a type-confusion flaw in Microsoft Edge (Chromium-based) that could allow remote code execution, rated Important with a CVSS 3.1 score of 7.5. Microsoft's advisory lists it as not exploited and not publicly disclosed. The advisory's fixed-build number conflicts with Edge's own release notes, so the exact patched version is unconfirmed.
