litellm v1.106.3

LiteLLM, an open-source library and proxy server that lets applications call many AI model providers through one interface, shipped v1.106.3 whose listed changes are two security fixes (GitHub release notes). The change that needs action is a new signing key for its Docker images and Helm charts. LiteLLM signs each image with cosign, and anyone deploying it can check that signature against the published public key, `cosign.pub`, before running the image. From this release on, verification against the old key from commit `0112e53` fails, so `cosign verify` scripts, CI checks and cluster admission policies such as Kyverno that pin the old public key need the new one from commit `e82a3c6`. The same change was backported to 1.103.8, 1.104.6 and 1.105.4.

Neither the release notes nor the pull request that swapped the key (#48103) gives a reason. When a user asked in issue #48215, a maintainer answered that the rotation was not routine and that the team has reason to believe the private half of the old key was exposed when an attacker exfiltrated credentials. That attack is the October 21 compromise in which a poisoned litellm 1.107.0, carrying a credential stealer and a backdoor, went out through the project's own release pipeline to PyPI and to several Docker tags (SafeDep; see the earlier Intel item). According to the maintainer, signatures made with the old key before 1.107.0 can still be trusted, but the 1.107.0 images carry a valid old-key signature and should be treated as compromised. A check that passes against the old key therefore no longer shows that an image is safe, which is why the pins have to move.

The second change removes the eMudhra root certificate authority from every certificate bundle the SDK, proxy and Docker images trust. A root authority is one the software accepts as a vouching source when it checks that an HTTPS connection really reaches the site it claims to. Pull request #47670 says the signing keys for eight eMudhra intermediate authorities leaked on October 17, so anyone holding them could issue a certificate for any site. Because LiteLLM still trusted the root those intermediates chain to, a forged certificate for a provider such as OpenAI would have been accepted. With the root removed, LiteLLM rejects certificates that chain to it.