LiteLLM 1.107.0が改ざんされていた件｜入れたかどうかの確かめ方、1.106.2での作り直しと鍵の作り直し

PythonのライブラリLiteLLMの1.107.0には、認証情報を盗むコードが入っていました。2026年10月21日20時39分〜22時23分（日本時間）にpipで1.107.0を入れた環境（バージョンを固定せずに更新した場合を含む）と、20時46分〜23時20分にDockerイメージのv1.107.0・latest・main-latest・main-stableを動かした環境は、乗っ取られたものとして扱い、不正なファイルを消して1.106.2で作り直し、その環境から届く鍵をすべて作り直してください。

結論：1.107.0を入れた・動かした環境は作り直し、鍵も作り直す

• 何が起きたか：LiteLLMのリリースの仕組みが乗っ取られ、認証情報を盗み、外からコードを実行させる道具を読み込むコードが入った1.107.0が、PyPIとDockerのレジストリに出されました
• 影響を受ける人：PyPIの litellm==1.107.0（wheel 7つすべて）を入れた人と、Dockerイメージの v1.107.0・latest・main-latest・main-stable を下の時間に取ってきて動かした人
• 影響を受けない人：1.106.2以前のバージョンだけを使っている人。LiteLLMは、それより前のバージョンはすべて安全だとしています。企業向けの非公開レジストリから取っている人も影響を受けていません
• 今の状態：1.107.0はPyPI・Docker Hub・GHCRから消されています。PyPIの最新は1.106.2で、Docker Hubの latest・main-latest・main-stable は1.106.2と同じイメージを指しています（10月22日8時27分（日本時間）時点）
• やること：影響を受けた環境ではpipを先に動かさず、不正なファイルを消し、裏で動き続けるプロセスを止め、環境をはじめから作り直します。そのうえで、その環境から届く鍵とパスワードをすべて作り直します

影響を受けたものと時間

LiteLLMの公式発表によると、次のとおりです（日本時間。かっこ内はUTC）。

不正なイメージのイメージインデックスのダイジェストは、ghcr.io/berriai/litellm とDocker Hubが sha256:1bbcb1443bc962e45f5aad53fe3d2c30600e0379715fb6c664cdd3ac126c339e、litellm-database が sha256:c00f9d92c427…、litellm-non_root が sha256:7b00e91cd2fe… で始まるものです。

GitHubにある公式の v1.107.0 のソースのタグには、不正なファイルは入っていません。不正な配布物は、攻撃者が用意したよく似た名前のリポジトリ（Berri-AI/litellm。本物は BerriAI/litellm）から作られていました。

自分の環境が影響を受けたか確かめる

LiteLLMは、上の時間にpipで1.107.0を入れたか、Dockerイメージを動かしたなら、乗っ取られたものとして扱うよう求めています。手がかりは、不正なファイル・Dockerイメージのダイジェスト・裏で動き続けるプロセスの3つです。

1. 不正なファイルが残っていないか

LiteLLMは、litellm-1.107.0.dist-info・cook.pth・sitecustomize.py を探すよう案内しています。影響を受けた環境では、pipを含めてPythonを起動するたびに cook.pth と sitecustomize.py がまた動くとしているので、Pythonを起動せず、シェルから探します。

Debian・UbuntuのOSのPythonにpipで入れた場合、置き場所は site-packages ではなく dist-packages です。どちらも探せるように、-packages で終わる場所を探します。ほかのユーザーやrootが入れた分も探すため、sudo を付けて動かします。

sudo find / -path '*-packages*' \( -name 'litellm-1.107.0.dist-info' -o -name 'cook.pth' -o -name 'cook.py' -o -name 'sitecustomize.py' \) 2>/dev/null

どれか1つでも見つかれば、影響を受けたことが確かです。ただし、LiteLLMは、見つからなくても安全だとは言えないとしています。上の時間に入れた・動かした覚えがあるなら、見つからなくても次の手順に進みます。

LiteLLMは pip show litellm でもバージョンを確かめられるとしていますが、pipもPythonを起動します。上の find で何も見つからなかった環境で使います。

pip show litellm

2. Dockerイメージのダイジェスト

手元にあるLiteLLMのイメージのダイジェストを出し、上のダイジェストと同じものがないかを見ます。

docker image ls --digests | grep -i litellm

LiteLLMのイメージから作ったコンテナと、作った日時は次で見られます。上の時間にイメージを取ってきて動かしていれば、そのコンテナは乗っ取られたものとして扱います。

docker ps -a --format '{{.ID}}  {{.Image}}  {{.CreatedAt}}' | grep -i litellm

3. 裏で動き続けるプロセス

LiteLLMによると、不正なコードは切り離されたPythonのプロセスを裏で動かし続け、そのプロセスが /tmp/remote_code_loader.lock をつかんでいます。このファイルをつかんでいるプロセスがあるかを見ます。ほかのユーザーのプロセスも出るように、sudo を付けて動かします。

ls -l /tmp/remote_code_loader.lock
sudo lsof /tmp/remote_code_loader.lock

lsof が入っていなければ、fuser でも見られます。

sudo fuser -v /tmp/remote_code_loader.lock

この確かめ方は、pipで入れたホストや仮想環境のためのものです。コンテナは、上のイメージのダイジェストで確かめます。

影響を受けたときにやること

LiteLLMが案内している手順です。最初に pip install を動かしてはいけません。Pythonを起動すると、不正なファイルがまた動きます。

1. 不正なファイルを消す

シェルから、影響を受けたすべての site-packages（Debian・Ubuntuでは dist-packages も）にある cook.pth・cook.py・sitecustomize.py と、__pycache__ の中の cook*.pyc・sitecustomize*.pyc を消します。/path/to/site-packages は、上の find で見つかった場所に置き換えます。

rm -f /path/to/site-packages/cook.pth /path/to/site-packages/cook.py /path/to/site-packages/sitecustomize.py
find /path/to/site-packages -path '*__pycache__*' \( -name 'cook*.pyc' -o -name 'sitecustomize*.pyc' \) -delete

2. 裏で動いているプロセスを止める

lsof や fuser で出てきたプロセスの番号（PID）を指定して止めます。

sudo kill PID

3. 1.106.2で作り直す

LiteLLMは、litellm==1.106.2 に固定して入れ直すよう求めていて、仮想環境（venv）やイメージをはじめから作り直すほうがよいとしています。古い仮想環境は消し、新しく作ってから入れます。

python3 -m venv .venv-new
. .venv-new/bin/activate
pip install 'litellm==1.106.2'

requirements.txt や pyproject.toml でも、当面は litellm==1.106.2 のようにバージョンを固定します。LiteLLMは、しばらくは1.106.2か、それより前に出たバージョンを明示して使うよう求めています。

Dockerは、latest などの動くタグではなく、バージョンのタグを指定して取り直し、コンテナを作り直します。

docker pull docker.io/litellm/litellm:v1.106.2

4. 鍵とパスワードをすべて作り直す

LiteLLMは、外のインターネットにつながるホストで1.107.0を一度でも入れたなら、情報は持ち出されたものと考えるよう求めています。そのホストから届いたものはすべて作り直します。LiteLLMが特に挙げているのは次のものです。

• そのインスタンスやタスクに付けたIAMロール
• LiteLLMのプロキシのデータベースに入れている、各AIサービスのAPIキーすべてと、マスターキー・仮想キー
• DATABASE_URL のパスワード
• そのホストで動いていたプロセスの環境変数に入っていた秘密の値すべて

OpenAI・Anthropic・GoogleのAPIキーの無効化と作り直しのしかたは、OpenCodeでAPIキー漏えいの可能性の記事にあります。

5. AWSで使われていないか確かめる

LiteLLMは、AWSのCloudTrailで、入れたころにそのインスタンスのロールから GetCallerIdentity が呼ばれていないかを見て、そのあとロールの認証情報が自分たちの環境の外から使われていないかを確かめるよう求めています。AWS CLIの lookup-events は1つのリージョンだけを探します。インスタンスのあるリージョンと us-east-1 の両方で、--region を付けて確かめます。ap-northeast-1 は、自分のリージョンに置き換えます。

aws cloudtrail lookup-events --region ap-northeast-1 --lookup-attributes AttributeKey=EventName,AttributeValue=GetCallerIdentity --start-time 2026-10-21T11:00:00Z
aws cloudtrail lookup-events --region us-east-1 --lookup-attributes AttributeKey=EventName,AttributeValue=GetCallerIdentity --start-time 2026-10-21T11:00:00Z

鍵を盗んだ人がほかのリージョンから呼んでいれば、記録はそのリージョンに残ります。すべてのリージョンの記録を残す証跡（trail）があれば、そちらで探します。ない場合は、使えるリージョンを1つずつ確かめます。

よくある質問

1.106.2やそれより前のバージョンは使っていて大丈夫ですか

LiteLLMは、1.107.0より前のバージョンはすべて安全だとしています。いまPyPIの最新は1.106.2です。

GitHubのソースから自分で作った場合は

LiteLLMによると、公式の v1.107.0 のタグには不正なファイルは入っていません。不正な配布物は、よく似た名前の別のリポジトリから作られたものです。

企業向けのLiteLLMは

非公開のレジストリから企業向けのリリースを取っている人は、影響を受けていないとしています。

なぜ起きたのですか

LiteLLMは、開発者3人のGitHub CLIの認証トークンが盗まれ、それを使ってリリースの仕組みの保護を外し、よく似た名前のリポジトリから作った配布物を出されたとしています。トークンが盗まれたきっかけについては、外から入れる状態だった社内のLiteLLMのログからトークンを取られたとみていて、調べを続けています。関わったトークンはすべて無効にしたとしています。通常のリリースは、安全に再開できると確かめられるまで止めています。

悪いパッケージを入れる前に止める仕組みについては、GitHub package firewallとはの記事を見てください。

参考リンク

• Contained: Oct 21, 2026 LiteLLM release v1.107.0 Compromised（LiteLLM）
• [SECURITY] litellm 1.107.0 compromised（BerriAI/litellm GitHub Issue #47826）
• litellm（PyPI）
• litellm/litellm のタグ（Docker Hub）