ハクソク

世界を動かす技術を、日本語で。

LiteLLM Pythonパッケージがサプライチェーン攻撃により侵害される

45日前原文(github.com)

概要

  • litellm==1.82.8 のPyPIホイールパッケージに 悪意ある.pthファイル が含まれる
  • Python起動時に 資格情報窃取スクリプト が自動実行される
  • 多様な機密情報 を収集し、外部サーバーへ送信
  • 全環境（開発・CI/CD・本番） が影響対象
  • 即時対応・認証情報のローテーション が推奨

litellm==1.82.8におけるサプライチェーン攻撃の概要

  • PyPI公開の litellm==1.82.8 ホイールパッケージに、 litellm_init.pth （34,628バイト）が含まれる

  • .pthファイル はPythonインタープリタ起動時に自動実行され、 import litellm は不要

  • RECORDファイル に悪意ある.pthファイルが明記されている

  • pip download litellm==1.82.8 --no-deps で再現可能

    • litellm_init.pth 内に次のような記述
      • import os, subprocess, sys; subprocess.Popen([sys.executable, "-c", "import base64; exec(base64.b64decode('...'))"])

悪意ある挙動の詳細解析

  • ペイロードは二重base64エンコード で秘匿化

  • デコード後の動作は以下の通り

    • ステージ1: 情報収集

      • システム情報取得（hostname, whoami, uname -a, ip addr, ip route）
      • 環境変数（printenv）：APIキーやシークレット含む
      • SSH鍵・設定ファイル（~/.ssh/各種ファイル）
      • Git認証情報（~/.gitconfig, ~/.git-credentials）
      • AWS認証情報（~/.aws/credentials, IMDSトークン取得）
      • Kubernetesシークレット（~/.kube/config, /etc/kubernetes/各種）
      • GCP, Azure, Docker, 各種パッケージマネージャ設定ファイル
      • シェル履歴（~/.bash_history 等）
      • 仮想通貨ウォレット・SSL/TLS秘密鍵・CI/CDシークレット
      • データベース認証情報・Webhook URL（Slack, Discord等）

    • ステージ2: 暗号化と外部送信

      • 収集データを一時ファイルに保存
      • openssl randでランダム32バイトの AES-256セッションキー 生成
      • openssl encでデータをAES-256-CBC暗号化
      • RSA公開鍵（ハードコード済み4096bit） でAESキーを暗号化
      • 2つのファイルを tpcp.tar.gz にまとめる
      • curlでhttps://models.litellm.cloud/ へPOST送信（攻撃者管理ドメイン）

技術的特徴・ステルス性

  • .pthファイル による自動実行：import不要、site-packages配置のみで発動
  • 二重base64エンコード でソースコードgrepを回避
  • 公式と異なるドメイン （litellm.cloud）へのデータ送信
  • RSA公開鍵 （冒頭64文字：MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAvahaZDo8mucujrT15ry+...）

影響範囲

  • litellm==1.82.8 をpip経由でインストールした全環境
    • ローカル開発マシン
    • CI/CDパイプライン
    • Dockerコンテナ
    • 本番サーバー
  • 全ての環境変数、SSH鍵、クラウド認証情報等が漏洩

対応・推奨アクション

  • PyPI ：litellm 1.82.8の即時削除・yank推奨
  • 利用者 ：
    • site-packages内に litellm_init.pth が存在するか確認
    • litellm 1.82.8インストール済みシステムの 全認証情報をローテーション
  • BerriAI ：PyPI公開権限・CI/CDパイプラインの監査推奨

発見・実行環境

  • OS： Ubuntu 24.04 (Dockerコンテナ)
  • Python： 3.13
  • pip：PyPIからインストール
  • 発見日： 2026-03-24

Hackerたちの意見

創業者とCTOのアカウントがハッキングされたみたいだね。 https://github.com/krrishdholakia

└

それとも、彼の会社がクソで、ただの盗みを働いてるのかもね。

└

最近のコミットは「teampcp」を名乗って責任を取る小さな編集ばかりで、これは最近のTrivyのハッキングを行ったグループだよね。 https://news.ycombinator.com/item?id=47475888

それに加えて、オーナーのアカウントも危ないかもしれないし、170以上の低品質なスパムコメントもあるよ。GitHubにはもっとマシなスパム検出システムを期待してたんだけど、これはちょっと許せないね。

└

おそらく、彼らがスティーラーでハッキングしたアカウントだと思う。

Harborをインストールしたばかりなのに、すぐにCPUがパンクしたよ。システムが完全にロックされる前にプロセスを確認できたのはラッキーだった。基本的に、grep -r rpcuser\rpcpasswordプロセスがフォークボムして、暗号ウォレットを探そうとしてたみたい。ハーネスから発生してたのを見て、殺したけど、運が良かった。バイナリから判断する限り、バックドアはインストールされてなかった。

└

Harnessって何？

└

ブラウザ使用でも同じ経験があった。litellmを依存関係としてインストールしてた。何も反応しなかったからMacを再起動したけど、運良く.github-credentialsに保存されてたのはGitHubとHugging Faceのトークンだけで、それを無効にした。これはconda環境の中だったけど、バックドアの可能性があるからOSを再インストールすべきかな？

これは最近のTeamPCPの活動に関連してるね。俺は反応して、最新のタイムラインを維持してる。これがみんなの参考になって、この事件を理解する助けになればいいな。 https://ramimac.me/trivy-teampcp/#phase-09

一度でもエージェント主導のハッキングがあれば、Claudeが書いた裏技Cがllvmやlinuxに入ってきて、最終的にみんなが「信頼の信頼」について考え直さなきゃいけなくなるんだろうね。

└

もうバックドア付きのコードを書ける人がいるって知ってるよね？

└

もしそんなことが起きたら、心配なのは世界中の敏感な政府サーバーが攻撃されて、そういう脅威者によって静かにどれだけの被害が出るかってことだよ。AWSやGCPみたいな巨大なハイパースケーラーも政府が使ってるから、可能性は壊滅的になるかもしれない。もし国家がハッキング攻撃を支援することに興味を持っていると仮定したら（実際、多くの国がそうしてる）、敵国を攻撃したり、優位に立つためにね。そうなると、被害は兆単位になるだろう。でも、今のところLinuxは安全だと思う。多分、一番注目されてるコードだし、確実に安全なものだと思う。LLVMはちょっと興味深いかもしれないけど、あまり目立たないかもしれない。でも、LLVMで働いてる人たちがしっかり資金を得て、すべてを注意深く見てくれることを願ってるよ。

└

安全でいるためには、内部APIを常に変えて、LLMがカーネルコードで役に立たないようにするしかない。

└

どのように反映するの？そのトークの主な焦点は、コンパイラのバイナリに感染させることが可能で、ソース分析では明らかにならず、バイナリが生成する他のバイナリに脆弱性を自己複製するということです。幸いなことに、その特定の問題は「解決」されましたが、まだ広く実装されてはいません。しかし、サプライチェーン攻撃の広範なアイデアは依然として難しいもので、AIはそれに対処する方法にはあまり関係ありません。例えば、OpenSSHを攻撃するために多くの人気ディストリビューションでsystemdに依存するようにパッチが当てられたビルドシステムのxz-utilsのバックドアはAIよりも前から存在していて、それは捕まったからこそ知られている攻撃です。AIがそういった攻撃の規模を助けるかもしれませんが、実際にすべての信頼性と堅牢性を改善するような解決策を提案している人は聞いたことがありません。[1] 多様な二重コンパイルによる信頼の信頼を完全に打ち消す https://arxiv.org/abs/1004.5534

一般的な質問なんだけど、フロンティアAI企業はこういうシナリオをトレーニングデータでどう扱ってるの？もし彼らがモデルを単純にトレーニングしたら、トレーニングデータの注入が可能になって、モデルが知らないうちに人をやっつけちゃうかもしれないよね。ラボはコードのバージョンに関連するCVEを付けて、どれが侵害されたかを示してるのかな（モデルに何をしないべきか教えるために）？それとも、良いことと悪いことを教えるために敵対的強化学習環境を使ってるのかな？どうしても侵害されたコードがトレーニングデータに含まれちゃうのは避けられないから、すごく気になるんだ。

└

AI企業がそんな対策を取ってるとは思えないけど、間違ってるかもしれないね。

└

みんな（Anthropicを除いて、彼らはちょっとセンスを保ってるみたいだけど）「データは多い方がいい」ってアプローチだから、盗まれたコンテンツ（あ、モデルね）のデータベースがクソみたいなものを記憶してるんだよね。

└

これはライブラリのオーナーのGitHubアカウントが侵害されたことらしいから、トレーニングデータの危険なコードとは関係ないシナリオだね。ほとんどのラボはこれに対処することをしてないと思うし、理論的にはより良いコードがより良い報酬を受けるべきだから、自然にトレーニングから外れることを期待してるんじゃないかな。

依存関係や開発環境を信頼できないよね。「もう」と言いたいけど、実際にはずっと前から信頼できなかった。開発コンテナは十分じゃなかったし、使いにくくて隔離も足りなかった。実際のガードレールやUIを持った完全なサンドボックスで、深い防御を持つ環境で作業を始める必要がある。VMの隔離やコンテナのプリミティブ、許可リスト、出口フィルター、seccomp、gvisorなど、もっと使いやすくする必要がある。エージェントのランタイムに求める要件と同じだし、この勢いを利用して開発環境をもっと安全にしよう！そんな環境ではコンテナがクラッシュして、違反が見えるから、それを削除して心配しなくて済む。これを日常的な可能性として扱うべきで、孤立したセキュリティインシデントとしては考えない方がいい。

└

コンテナからクレデンシャルを分離するプロジェクトについて、意見を聞かせてほしいです: https://github.com/calebfaruki/tightbeam https://github.com/calebfaruki/airlock これがまさに私が守ろうとしているものなんです。

└

そうなんです…私は文字通りの仮想マシンを出荷可能にするオープンソース技術に取り組んでいます。つまり、中にあるすべてを凍結し、vm/hypervisorによってサンドボックス化された状態で、リアルなLinux VMなのでコンテナのサポートもあります。あなたが言った問題は私にとってすごく共感できるもので、だからこそこれを作っているんです。一緒に解決することに興味がありますか？: https://github.com/smol-machines/smolvm

└

すべてのインポートされたモジュールがデフォルトで独自のサンドボックスに入るプログラミング言語が必要だね。

└

コンテナはこういう情報の盗難をかなり防いでくれる。明示的に提供された認証情報だけが漏れちゃう。

└

過去50年のセキュリティのショートカットが今になって問題を引き起こしてる。ソフトウェアの世界は、みんながお互いを信頼する場所だったけど、そろそろそれも終わりそう。サンドボックスは絶対必要だけど、それだけじゃない。全体のセキュリティモデルを見直す必要があるよ。

└

依存関係や開発環境を信頼できないし、検証もできない。私の個人的なプロジェクト（PythonとRustのプロジェクト）では、ほとんどの依存関係を排除して、自分が必要なことだけをする代替品を使ってる。未来のプロジェクトでは依存関係がかなり減ると思う。あと、通常は現在のバージョンに脆弱性が知られているか、後のバージョンに必要な機能がある場合にのみ依存関係を更新するようにしてる。できるだけ最新バージョンにはしないようにしてるよ。これは「多くの目」の原則の下で、すべてのプロジェクトに適用してる。脆弱性を見つけるのには時間がかかるし、新しいアップデートは少し古いバージョンよりリスクが高いからね。ただ、プロジェクトにバグを報告する場合は、最新バージョンでテストして報告するよ。

└

それじゃ解決にならないよ。依存関係を信頼できない、または検証できないし、悪意がある場合は、サンドボックスが守ってくれる以上の大きな問題があるってことだよ。たとえサンドボックス内で、ホストマシンが安全でも、その悪意のあるコードを本番環境で使うことになるんじゃないかな。

LiteLLMのメンテナーです。まだ進行中の状況ですが、今のところ分かっていることは以下の通りです。1. どうやらこれは私たちのci/cdで使っているtrivvyから発生したようです - https://github.com/search?q=repo%3ABerriAI%2Flitellm%20trivy... https://ramimac.me/trivy-teampcp/#phase-09 2. プロキシのDockerを使っている場合は、影響を受けていません。requirements.txtでバージョンを固定しています。3. パッケージはpypiで隔離されていて、すべてのダウンロードがブロックされています。問題を調査中で、どうやって強化できるか考えています。申し訳ありません。 - Krrish

└
  1. どうやらこれは私たちのci/cdで使っているtrivvyから発生したようです。短い時間の間にこれに気づかなかったの？どうしてクレデンシャルを回転させてtrivyの侵害を軽減しなかったの？
└
  • Krrish あなたのアカウントは完全に侵害されたの？（あなたのアカウントでTeamPCPが行ったコミットから判断すると）litellmを下流で使っているすべてのプロジェクトと連絡を取っていますか？それらは安全なの？（私は安全ではないと思っています）CI/CDで使われているtrivvyの脆弱性からどうやってあなたのアカウントが侵害されたのか理解できません。
└

1.82.8だけなの？それとも以前のバージョンも影響を受けているの？

└

すべてのダウンロードをブロックする決定はかなり混乱を招くよ。特に、既知の良いバージョンに固定している人たちにとってはね。uv runで起動してるシステムがたくさん壊れちゃった。

彼らの前のリリースは静的解析で簡単に見つかるだろうね。PTHは新しい技術だ。新しい依存関係はすべて静的解析にかけて、最新バージョンはインストールしない方がいいよ。Python用の静的解析を実装したんだけど、こういうインジェクションの90%近くを検出できるよ。 https://github.com/rushter/hexora

└

面白いツールだね、絶対試してみるよ。ちょっと気になるんだけど、hexora自体とその依存関係が侵害されてないか確認するツール（hexoraチェッカー）ってあるのかな？もしあったら、hexoraチェッカー用の別のツールも必要になりそうだね…。

我々はペイロードを分析したよ。技術的な詳細はここにあるよ: https://safedep.io/malicious-litellm-1-82-8-analysis/ 他の知ってるPyPIパッケージでも、似たような攻撃ベクター（pthインジェクション）やシグネチャを見てるところだよ。