LiteLLM’s releases from 24 October open with a notice that costs money if you skim it: “The image-signing key has changed. Starting with this release, every Docker image and Helm chart is signed with the new cosign key from commit e82a3c6. Verifying with the previous key from commit 0112e53 will fail.”

Nothing about the images is broken; the trust anchor moved. Anyone whose pipeline checks signatures against a pinned cosign.pub is now checking against a key none of these images are signed with, so verification fails on the new releases until the pin is updated. Images from earlier releases were signed with that key and still verify against it; the switch is at this release. The release note names where those pins usually live: “cosign verify scripts, CI checks, and admission policies such as Kyverno, Sigstore policy-controller or Connaisseur.”

The new key, and how to check it

The note publishes the new cosign.pub SHA-256 as e3fe3e08c44b16407fe0b37c43b4f8b603b3a0f4ee74c29e647bc022d762c2c0, and the file at commit e82a3c6 hashes to exactly that value. That is the check worth doing before you trust a rotation notice: fetch the key yourself, hash it, compare.

The documented verification command, reproduced as the release note gives it:

cosign verify \
  --key https://raw.githubusercontent.com/BerriAI/litellm/e82a3c646908ba0a6ee0beddc4310d7a6cac4065/cosign.pub \
  ghcr.io/berriai/litellm:v1.106.3

The note says the same command covers litellm-database, litellm-non_root and the docker.io/litellm/* images. What was checked here is the key file’s hash against the published value, nothing more; no image signature was verified end to end in this piece.

The other change in the same releases

The second deployment item is a trust-store change: “Removed the eMudhra root CA from every certificate bundle the SDK, proxy and Docker images trust (#47670, #47969, #48139).”

So the CA story that has run through this month reaches LiteLLM’s own bundles, not just whatever base image it inherits. If anything in your stack depends on that root being present inside LiteLLM’s image, it will now fail to validate, which is the intended outcome of a compromised CA being distrusted and worth knowing before you debug a connection error as an application bug.

Which versions carry both

The 1.106.3 record, published 24 October, marks both changes as “Also in 1.103.8, 1.104.6, 1.105.4”, and the 1.105.4 record carries the same notice with its own tag in the command, its own superscript naming only 1.103.8 and 1.104.6. So the changes travel together across the backport lines rather than landing only on the newest.

On the version question, the observable fact is the tag list, which holds ten entries: v1.107.0-rc.2, v1.107.0-rc.1, v1.107.0-dev.3, v1.107.0-dev.2, v1.107.0-dev.1, then v1.106.3, v1.106.2, v1.106.1, v1.106.0 and v1.106.0-rc.4. There is no stable v1.107.0 tag, so the stable train resumes at 1.106.3 with the three backports beside it. The release notes do not say why, and this piece will not guess; what matters is that 1.106.3 is the newest stable release carrying both changes.

What to do

If you verify LiteLLM images, replace the pinned key everywhere it appears, with the hash check above as your acceptance test. If you run admission policies, update the policy’s key reference, because a failing policy blocks the new images rather than warning about them.

If you pinned 1.107.0, move to 1.106.3 or one of the backports. Our 22 October piece on the PyPI compromise covered what happened to that version line and what to do about a possibly infected install; this one is about the releases that followed it.

And if you do not verify signatures today, this is the release to start, since a signing key you never check is the kind of thing that gets rotated without anyone noticing and then breaks a deploy six months later.

Sources: the LiteLLM v1.106.3 release record, the v1.105.4 release record, the new cosign.pub at commit e82a3c6, and the repository tag list.