LiteLLM 1.107.0に鍵を盗む仕組み エージェントの設定も狙う
複数のLLMを1つの形で呼べるLiteLLMの1.107.0が、日本時間10月21日夜にPyPIとDockerで配られ、中に認証情報を盗む仕組みと遠隔でコードを動かす裏口が入っていた。LiteLLMは開発者3人のGitHubの認証情報が盗まれたと公表し、配布は取り下げた。盗む対象にはClaude Code、Codex、Cursorの設定も含まれる。入れた環境は乗っ取られた前提で、鍵をすべて替える必要がある。
記事の内容を自社でどう進めるか、内容が固まっていない段階でも相談できます。仕事の相談
毎週 1 回、その週の記事から 5 本と実践の 1 本を選んでメールで届けます。ニュースレターを購読する(無料)

複数のLLMを1つの形で呼べる道具LiteLLMの1.107.0に、認証情報を盗む仕組みと、遠隔でコードを動かす裏口が入っていた。配られたのは日本時間10月21日の夜で、PyPIでは20時39分から22時23分まで、Dockerの一部の版は23時20分ごろまで手に入った。LiteLLMは同日、事故の報告を出し、配布を取り下げた。Claude CodeやCodexを自分のモデルにつなぐ中継役としてLiteLLMを使っている人は、手元の版を確かめたい。
Pythonが動くだけで盗まれる
調べたSafeDepの分析によると、1.107.0の7つのwheelはすべて、site-packagesにcook.pth、cook.py、sitecustomize.pyの3つのファイルを置く。どれもPythonが起動するたびに読み込まれるので、litellmをimportしない処理でも、pipやエディターの補助の処理でも動く。
cook.pyは、SSHの鍵、AWSやGoogle Cloudの認証情報、CIの秘密、ブラウザーに保存したパスワード、環境変数を集め、暗号化して外へ送る。集める先にはClaude Code、Claude Desktop、Cursor、VS Codeのmcp.json、Codexのauth.json、Gemini CLIの設定も並ぶ。LiteLLMの中継サーバーのデータベースからは、登録したLLMのAPIキーの表をまるごと抜く。sitecustomize.pyは1時間ごとにGitHub上のファイルから接続先を読み、そこから受け取ったコードを動かす裏口だった。接続先を書いたGitHubのアカウントは約2時間後に消えたが、それまでに次の段のコードを受け取った環境もありうる。
盗まれたのは開発者のGitHubの鍵
LiteLLMの事故の報告によると、攻撃者は開発者3人のGitHubアカウントを使った。GitHub CLIのOAuthトークンが盗まれたとみられ、1人の権限で公開の手順を書き換えて走らせ、別の1人の権限で承認した(会社の申告)。中身は攻撃者が用意した似た名前のリポジトリから作られ、正規のv1.107.0のタグには悪い部分は無い。トークンを得た経路は、報告の時点では書かれていない。ただ、GitHubのissueには日本時間22日5時31分、LiteLLM側から、攻撃の流れを特定したと考えている、詳しい説明を後で出す、という書き込みがあった。
Dockerでは、latest、main-latest、main-stableの3つの名前も、同じ時間帯は汚染された版を指していた。GitHubの置き場(ghcr.io/berriai/litellmと、-database、-non_root)でも同じ4つの名前が、日本時間22時51分ごろまで汚染された版を指していた。版を固定せずにDockerで中継サーバーを立ち上げた人も対象になる。ほかの版は安全で、企業向けの非公開の配布も影響を受けていないという(会社の申告)。その非公開の配布では、10月27日に公表する予定の別の脆弱性の修正版が先に配られている、と報告は書いている(会社の申告)。SafeDepも、1.106.2、1.107.0rc1、rc2は問題ないと書いている。最初に見つけた外部の研究者のGitHubのissueには、その後、攻撃の後の動きを見たというWizの書き込みも付いた。
まずpipを走らせない
報告が勧める手順は順番が大事だ。確かめるのは、まずシェルでのファイル探しからにする。site-packagesなどにlitellm-1.107.0.dist-info、cook.pth、sitecustomize.pyがあれば、入っていた証拠になる。pip show litellmでも版は見られるが、pipもPythonを起動するので、1.107.0が入った環境ではそれだけで仕組みがもう一度動く。使うのは後回しにしたい。見つかったら、pipでの入れ直しから始めてはいけない。シェルからcook.pth、cook.py、sitecustomize.pyと、そのキャッシュを消し、/tmp/remote_code_loader.lockを握っているPythonの常駐の処理を止める。そのうえで1.106.2に固定して入れ直す。報告は、Dockerのimageや仮想環境をゼロから作り直す方がよいと勧めている。
外とつながる機械で一度でも動いたなら、盗まれた前提で動く。目印のファイルが無くても安全の証明にはならない、と報告は念を押す。替えるのは、クラウドの権限、中継サーバーに登録したLLMのAPIキーとLiteLLMの鍵、データベースのパスワード、環境にあった秘密のすべてだ。AWSで動かしていたなら、入れた時刻の前後に、その機械の権限でGetCallerIdentityが呼ばれていないかをCloudTrailで見て、続けてその権限が自分の環境の外から使われていないかを確かめるよう、報告は求めている。手元でClaude CodeやCodexにログインしていたなら、その認証も替えたい(編集部の読み)。
編集部の見方
コーディングエージェントの設定ファイルが、盗む側の決まった標的になった。版を固定せずにpip install litellmやDockerのlatestを使う作り方は、こうした事故をそのまま受け取る。小さなチームでも、中継役やエージェントの周りの道具は版を固定し、更新は1日置いてから入れる、という守り方が要る。今回の入口がGitHub CLIのトークンだった点も、手元にトークンを置きっぱなしにする人には人ごとではない(編集部の読み)。
出典
に確認(日本時間)
- 分析(safedep.io)
- 事故の報告(docs.litellm.ai)
- GitHubのissue(github.com)
この記事は役に立ちましたか
ありがとうございます
ありがとうございます



