If you verify LiteLLM's Docker images or Helm charts with cosign, update your verify scripts and Kubernetes admission policies to LiteLLM's new signing key, from commit e82a3c6, which LiteLLM introduced with the v1.103.8 release on October 24, 2026. Keep the old key from commit 0112e53 for v1.106.2 and earlier images: check each version against the key it was signed with, rather than swapping one key for the other. Separately, LiteLLM's October 23, 2026 postmortem revises the cause it first gave for the v1.107.0 supply-chain compromise.

#What changed?

LiteLLM's v1.103.8 release notes say: "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."

LiteLLM tells users to "Update anything that pins the old cosign.pub: cosign verify scripts, CI checks, and admission policies such as Kyverno, Sigstore policy-controller or Connaisseur." It publishes the new key's fingerprint: "New cosign.pub SHA-256: e3fe3e08c44b16407fe0b37c43b4f8b603b3a0f4ee74c29e647bc022d762c2c0".

The change was made in pull request #48103, merged on October 23, 2026, which "Replaces cosign.pub with the new image-signing public key and pins the README verify command to the commit that introduces it (e82a3c6)." The old key was added in commit 0112e53 on March 31, 2026.

LiteLLM does not say why it rotated the key. Its postmortem says the attacker's run of the release pipeline "signed and published v1.107.0," and StepSecurity reported that the malicious artifacts were "built, signed, and published by the legitimate pipeline with valid provenance." LiteLLM has not linked those facts to the key change.

#Who is affected and when?

Anyone who checks LiteLLM image signatures with cosign or an admission controller. The new key applies from v1.103.8, published October 24, 2026.

Older images still use the old key. In a dotsbot.co check on October 24, 2026, v1.103.8 images passed verification with the new key and failed with the old key, while v1.106.2, the version LiteLLM told users to pin after the attack, passed only with the old key and failed with the new one. A policy that swaps the old key for the new one will start rejecting v1.106.2 and earlier images.

LiteLLM backported the key change to its 1.104.x, 1.105.x and 1.106.x stable branches. Version 1.104.6 appeared on PyPI and Docker Hub on October 24, 2026, and our check found it signed with the new key; its GitHub release was published at 08:40 UTC (14:10 IST) that day. LiteLLM published v1.105.4 at 08:52 UTC (14:22 IST) and v1.106.3 at 09:34 UTC (15:04 IST) on October 24, 2026, and LiteLLM's notes for both say they are signed with the new key from commit e82a3c6. We did not run cosign on those two releases. v1.106.3 is the next release after v1.106.2 on the 1.106 line. Our analysis: if you move from v1.106.2 to v1.106.3, your policy must accept the new key for it.

LiteLLM's own Docker Image Security Guide, last updated October 23, 2026, still says "The signing key was introduced in commit 0112e53," and its Sigstore policy-controller example pastes the old public key inline.

#What should you do?

Find every place that pins LiteLLM's old key. LiteLLM lists:

  • cosign verify scripts
  • CI checks
  • admission policies such as Kyverno, Sigstore policy-controller or Connaisseur

Include policies that paste the key inline, like the example in LiteLLM's guide. Then:

  1. Verify v1.103.8 and later with the new key. LiteLLM's command, written on one line: cosign verify --key https://raw.githubusercontent.com/BerriAI/litellm/e82a3c646908ba0a6ee0beddc4310d7a6cac4065/cosign.pub ghcr.io/berriai/litellm:v1.103.8. LiteLLM notes: "Same command for litellm-database, litellm-non_root and the docker.io/litellm/* images." Its README says pinning to a commit is "the strongest way to ensure you are using the published signing key."
  2. Check the key file. Its SHA-256 should be e3fe3e08c44b16407fe0b37c43b4f8b603b3a0f4ee74c29e647bc022d762c2c0, per LiteLLM.
  3. Keep the old key for older images. For v1.106.2 and earlier, verify with the key from commit 0112e53, as LiteLLM's v1.106.2 notes do, written on one line: cosign verify --key https://raw.githubusercontent.com/BerriAI/litellm/0112e53046018d726492c814b3644b7d376029d0/cosign.pub ghcr.io/berriai/litellm:v1.106.2. Our analysis: either map each version to its key, or trust both keys until all your deployments run new-key releases.
  4. Do not copy the old docs. Until LiteLLM updates its Docker Image Security Guide, take commands from the v1.103.8 release notes or the README.
  5. If you ran 1.107.0, the cleanup and key-rotation steps in our original article still apply.

#How did it happen?

LiteLLM has revised the cause it first gave. In its initial explanation, LiteLLM said it had seen cases in which "Claude Code will embed a user's GitHub CLI OAuth token into a response body, and in situations where response bodies are logged, these tokens may appear in LiteLLM logs." Our October 22, 2026 article reported that first explanation at the time.

The postmortem replaces it. "Our first post suspected the tokens were taken from the logs of an internal LiteLLM deployment. The request logs show the first token came from a different service," LiteLLM wrote, calling the postmortem "the canonical source of truth."

According to LiteLLM's postmortem:

  • On May 27, 2026, a configuration file committed to a public LiteLLM-Labs repository "inadvertently contained the master key to a deployment of the LiteLLM Agent Platform." LiteLLM says "key revocation did not occur for the master key."
  • The platform held "a GitHub CLI OAuth token associated with our GitHub organization owner's account," which LiteLLM says "was not associated with a service account and was not scoped down."
  • On October 10, the attacker used the master key to extract that token. "From this point onwards, the threat actor had owner-level access to all repositories in our GitHub."
  • The attacker then obtained tokens of "two engineers with maintainer privileges."
  • A release normally needed approval from "a special account locked to a physical device in our office." LiteLLM says that rule had been relaxed, "allowing any two engineers to trigger and approve a release." Its incident post dates the change to Monday, October 19, 2026.

LiteLLM says it is "revoking every token associated with every internal system and vendor platform." Socket, an independent security firm, reported "a compromise window of at least eleven days, from October 10 through the release attack on October 21."

The affected releases are unchanged: litellm 1.107.0 on PyPI and the v1.107.0, latest, main-latest and main-stable Docker images. GitHub's malware advisory GHSA-92x9-889m-jgmw lists 1.107.0; no CVE has been issued.

#How does it compare?

This is a follow-up to our report on the LiteLLM 1.107.0 compromise. LiteLLM credits Trail of Bits' work under Patch the Planet, the program behind our coverage of two critical PHP flaws. For another case of exposed provider keys, see the unrelated OpenCode Console breach.

#What is still unclear?

  • Why the key changed. LiteLLM has not said.
  • Older images. LiteLLM has not said whether it will re-sign older images with the new key.
  • Untested releases. We have not run cosign on 1.105.4 or 1.106.3; their new-key signing is per LiteLLM's notes.
  • Process changes. LiteLLM says, "We’ll share that next week," in a post dated October 23, 2026.