Learn/Remade with RustDigital Freedom

The LiteLLM Compromise Put Malware in Version 1.107.0

The LiteLLM compromise published malware as version 1.107.0 on 21 October 2026. mata.network does not install that package. Deputy will not swap sealed crate bytes.

Signed by M·
An open cardboard carton with crumpled white paper on a wooden table, closed cartons on a metal shelf behind it
What was the LiteLLM compromise on 21 October 2026?

The LiteLLM compromise published version 1.107.0 to PyPI and Docker with malware that steals credentials and can run code. The project pulled those releases the same day. Earlier versions were not affected.

In the early morning of 21 October 2026, LiteLLM's release pipeline was compromised. Version 1.107.0 went to PyPI and to Docker with compiled malware that steals credentials and can load tools to run code. LiteLLM's own note says the incident is contained and the investigation is still open. The bad wheels and images have been pulled. Earlier versions are safe. The private enterprise release was not in the blast.

This is a supply-chain hack, not a memory bug. Three developer GitHub credentials were used to publish the release. A rewrite of the proxy in Rust would not have stopped that login. What stops the install, on a stack that does not take latest from a public registry at deploy time, is a lockfile and a vault. That tool, for Rust, is Deputy. The catalog around it is Remade with Rust.

Trust is a version whose bytes you have already checked, not a tag named latest. Security is a build that reads a vault you hold, so a stolen maintainer key cannot swap the crate under you. Incentive is not paying for an AI gateway whose morning release was the malware. The Electronic Frontier Foundation has documented what happens when the package you fetch is no longer the package you reviewed.

How LiteLLM v1.107.0 Reached PyPI and Docker

LiteLLM gives the window in UTC. PyPI wheels for v1.107.0 were bad from 11:39 to 13:23, then pulled. Docker images tagged v1.107.0, latest, main-latest, and main-stable were bad from 11:46 to 14:20. The v1.107.0 image was removed. The floating tags were pointed back at clean sources. Wiz describes the added code as a credential stealer aimed at browser, cloud, and AI secrets, plus a dormant channel that can run code. That is enough to say what the package was. It is not a map of the malware.

The project says attackers used three unique developer GitHub credentials. As a temporary step, LiteLLM removed all but one unaffected user from the GitHub organization, and cut trusted links from the public registries back to that organization so a further publish would not ride the old path. Maintainer credentials were revoked down to what the investigation still needs. Customers on the private enterprise build were not hit. If your install was not v1.107.0, and not a floating tag that pointed at it during those hours, this publish did not land on you.

LiteLLM v1.107.0 Is a Stolen Key, Not a Language Bug

People will ask whether Remade with Rust would have made this impossible. It would not. The publisher was a real maintainer account. The bytes were whatever that account uploaded. Memory safety does not check a GitHub password. The NIST Secure Software Development Framework treats the dependency you accept as a decision, not a background fetch. That decision is the part a vault can enforce. The stolen login is the part only the project can revoke, and LiteLLM says it did.

A floating tag made the LiteLLM compromise wider than one version

latest, main-latest, and main-stable moved with the bad image. Anyone who deploys those tags without pinning a digest took the malware even if they never typed 1.107.0. A lockfile that names a digest, or a crate version whose hash you have sealed, does not follow a tag across the morning. Deputy keeps a history of the hash it has seen for a crate and version. If that version comes back with different bytes, the fetch stops. Cargo's cache would update. The vault does not.

The LiteLLM compromise does not rewrite the versions you already had

LiteLLM is explicit: previous versions are safe. This was a new publish, not a silent edit of 1.106 and everything under it. That distinction matters. A tool that only notices a changed hash of a version you already sealed will not, by itself, refuse a brand-new version number. A person still has to put the new version in the lockfile. On mata.network that person is not adding LiteLLM. The site does not install it.

GitHub credentials were the door for LiteLLM v1.107.0

Three accounts. Not a buffer overflow in the proxy. The CI story, as LiteLLM tells it, is a release pipeline that accepted those credentials and shipped. They have since narrowed who can publish. The FTC's note on software supply-chain claims is a reminder that "we use open source" is not a control. A control is who may sign a release, and whether your build will take it before a human looks.

mata.network Did Not Install LiteLLM v1.107.0

The website is Rust. Local models on this stack are FFAI, not a pip package that updated itself at 11:39 UTC. There is no LiteLLM wheel in the site's build. A machine you personally upgraded to v1.107.0 during the window is outside that sentence. Remove that version. The project's note is the source for which tags were bad and when.

Deputy seals Rust crates so a registry cannot swap them

Deputy reads Cargo.lock, fetches each pinned crate once, checks the bytes against the lockfile hash, and seals them in a store you hold. Later builds read the vault. A crates.io republish of a version you already sealed, with a new hash, stops the build. That is the Rust-shaped answer to the class of attack where the same version number grows new bytes. It is the piece Remade with Rust puts under the distributed cloud, described in what Deputy does. It is not a scanner for PyPI, and it should not be described as one.

FFAI stays on the machine instead of a gateway you pip-install

The reason a household AI stack got interested in LiteLLM is the wish for one interface over many models. FFAI is that wish pointed at engines that run here: speech, detection, and the rest of the local suite, in Rust, the same family as Diana. The importance of Remade with Rust is why that family is not a pip gateway. ragconverter.com turns files into chunks in the browser. DLDeploy is the same refusal on a board: the device does not phone a vendor account to boot. None of those installed v1.107.0. The Freedom Guide is where a person starts.

A new version still needs a person

Deputy will not silently adopt LiteLLM v1.107.0, because that package is not a crate in this build, and because a new version number is not pulled at deploy time. The remaining duty is human. If a lockfile change proposes a dependency you did not ask for, you do not merge it because the tag moved. Ship notes when the remade stack itself changes go to futureweb.news. The LiteLLM compromise is the morning's proof that latest is a person you have not met, holding a credential you did not issue.

FAQ

Short answers already in this article.

How long was LiteLLM v1.107.0 malicious on PyPI?

LiteLLM says the PyPI wheels for v1.107.0 were compromised from 11:39 UTC to 13:23 UTC on 21 October 2026, then pulled. Docker tags including v1.107.0, latest, main-latest, and main-stable were bad from 11:46 UTC to 14:20 UTC.

Did the LiteLLM compromise rewrite old releases?

LiteLLM says all previous versions are safe, and customers on the private enterprise release were not affected. The bad publish was v1.107.0 and the floating tags that pointed at it. If you did not install that version, you did not take this package.

Would Rust alone have stopped the LiteLLM compromise?

No. Three developer GitHub credentials were used to publish the release. A memory-safe rewrite does not stop a stolen maintainer login. The relevant control is refusing to install a brand-new version the hour it appears.

Does mata.network install the LiteLLM compromise?

The site does not pip-install LiteLLM. Local AI on this stack is FFAI, in Rust. A Python environment that installed v1.107.0 during the window is a different machine, and that version should not stay installed.

How does Deputy relate to a LiteLLM compromise?

Deputy vaults Rust crates from Cargo.lock and refuses a version whose bytes change after it was sealed. Builds then read the vault, not the registry. A new version still enters only when a person changes the lockfile.