LiteLLM 1.82.8のサプライチェーン攻撃、Claude Codeのスクリーン操作、OpenAIのMicrosoftリスク開示 (2026-03-24)
LiteLLM 1.82.8のサプライチェーン攻撃：importしなくても認証情報は盗まれる
litellm==1.82.8 をインストールした環境では、import litellm を一度も実行していなくても、Pythonインタープリタが起動するたびに認証情報が盗まれ続ける。
攻撃の核心は .pth ファイルの仕様にある。site-packages/ 以下に置かれた .pth ファイルは、Pythonインタープリタ起動時に自動で処理される。
【前提知識】.pth ファイルは本来、sys.path にディレクトリを追加するためのテキストファイルだ。しかし import で始まる行はPythonコードとして実行される仕様（PEP 302以前からの挙動）があり、これが今回悪用された。pip install 時に RECORD ファイルへ正規エントリとして登録されるため、pip show や pip check では異常を検出できない。python manage.py runserver でも pytest でも python -c "print(1)" でも、Pythonを起動した瞬間にペイロードが走る。
今回埋め込まれた litellm_init.pth（34,628バイト）の構造はこうだ。
import os, subprocess, sys; subprocess.Popen([sys.executable, "-c", "import base64; exec(base64.b64decode('...'))"])
ダブルbase64エンコードで難読化されており、単純な grep では検出できない。収集対象は以下に及ぶ。
- 全環境変数（
printenvの出力そのもの） ~/.ssh/以下の秘密鍵・authorized_keys・known_hosts- AWS/GCP/Azure/Kubernetes の認証情報ファイル
~/.gitconfig・~/.git-credentials- シェル履歴（
~/.bash_historyなど） - 暗号通貨ウォレット（Bitcoin/Ethereum/Solana など）
- CI/CDの設定ファイル（
Jenkinsfile・.gitlab-ci.ymlなど）
収集データはAES-256-CBCで暗号化され、さらにハードコードされた4096ビットRSA公開鍵でセッションキーを暗号化した上で https://models.litellm.cloud/ に送信される。
（exfiltration先のドメインが公式の litellm.ai ではなく litellm.cloud である点は意図的な偽装だ。litellm.ai だけをファイアウォールで許可していた環境でも素通りする。）
この攻撃が技術的に洗練されている点が二つある。
一つ目は .pth ファイルという攻撃ベクタの選択だ。setup.py や __init__.py への悪意あるコード埋め込みはコードレビューや静的解析の対象になりやすい。.pth ファイルはパッケージの機能とは無関係に見え、かつ RECORD ファイルに正規のエントリとして記載されているため、パッケージの整合性チェックをパスしてしまう。
二つ目は Popen による非同期実行だ。メインプロセスをブロックしないため、ユーザーはPythonの起動が遅くなったことすら気づかない。
LiteLLMはOpenAI・Anthropic・Geminiなど複数LLMプロバイダーを統一インターフェースで扱うライブラリで、API Gatewayとして本番環境に置かれるケースが多い。つまり OPENAI_API_KEY・ANTHROPIC_API_KEY が環境変数に存在する状態でこのパッケージが動いていた可能性が高い。CI/CDパイプラインでの利用も多く、GitHub ActionsのシークレットがPythonプロセスの環境変数として見えていれば、それも盗まれている。
BerriAIのPyPI公開パイプライン自体が侵害された可能性が高い。1.82.8 以外のバージョンの安全性は現時点で未検証だ。
今すぐやること
まず以下のコマンドで .pth ファイルを確認する。感染していれば即座に分かる。
【補足】上記コマンドで何も出力されない場合でも、既にデータが送信済みである可能性は排除できない。.pth ファイルはアンインストール後に削除されるが、送信済みの認証情報は無効化されない。検出結果に関わらず、1.82.8 をインストールした期間中に環境変数に存在した全シークレットのローテートが必要だ。
find $(python -c "import site; print(site.getsitepackages()[0])") -name "*.pth" | xargs grep -l "subprocess\|base64\|exec"
litellm==1.82.8 をインストールしたことがある環境では、環境変数に存在した全てのAPIキー・トークン・パスワードをローテートする。「使っていなかった」は関係ない。Pythonが起動した時点でペイロードは走っている。
Claude CodeとCoworkのスクリーン操作：「APIがないから自動化できない」という制約が消える
AnthropicがClaude CodeとCoworkにコンピュータ操作機能を統合した。SlackやGoogle Workspaceといった対応サービスへのコネクタを優先しつつ、コネクタが存在しない場合はブラウザ・マウス・キーボード・ディスプレイを直接制御してタスクを完了する。
重要なのはこの「フォールバック設計」だ。エージェントが操作できる対象の範囲が「APIが存在するサービス」から「画面に表示されているもの全て」に拡張された。
これまでAIエージェントに外部サービスを操作させるには、APIキーの取得・認証フローの実装・レスポンス形式のパース処理が必要だった。その統合コストが払えない場合、エージェントの能力は実質的に制限されていた。スクリーン操作によるフォールバックが実用水準に達すると、レガシーシステム・社内専用ツール・APIを公開していないSaaSが、エージェントの操作対象に入ってくる。
現時点ではmacOS限定・Claude ProおよびMaxサブスクライバー向けのリサーチプレビューだ。Anthropic自身が「どこで機能してどこで失敗するかを学ぶために早期公開している」と明言しており、複雑なタスクは再試行が必要なケースがあること、スクリーン経由の操作は直接統合より遅いことを正直に認めている。
権限管理の問題も表面化する。エージェントがマウスとキーボードを直接制御するということは、ユーザーがログイン済みの全てのサービスに対してアクセス権を持つことを意味する。Anthropicは「明示的な許可を必ず求める」としているが、その許可の粒度がどこまで細かいかは現時点では不明だ。
設計上の判断
Claude Codeを使った自動化ワークフローを設計しているなら、MCP等の直接統合の整備を優先すべきだ。スクリーン操作フォールバックは速度が遅く安定性も低い。直接統合があるタスクとスクリーン操作に頼るタスクを明示的に分けてアーキテクチャを組む必要がある。
【用語】MCP（Model Context Protocol）はAnthropicが策定したオープン標準で、AIエージェントが外部ツール・データソース・サービスと構造化された形で通信するためのプロトコルだ。スクリーン操作フォールバックと対比される「直接統合」の主要な実装手段として位置づけられている。
エージェントにコンピュータ操作権限を与える設計を検討しているなら、権限スコープの設計を先に固める。タスクごとに操作可能なアプリ・URLレンジ・ファイルパスを制限する仕組みを、機能を使い始める前に用意する。「何でもできる」エージェントは、誤操作や意図しないデータアクセスのリスクを一気に引き上げる。
macOS限定という制約は今後外れる可能性が高い。Windowsやクラウド環境への展開を見越して、エージェントが操作する処理の「画面依存度」を今のうちに棚卸しておくと、移行コストを抑えられる。
OpenAIがMicrosoftをIPO前文書でリスクとして開示：クラウド依存の構造問題が表面化
OpenAIは非公開のプレIPO文書の中で、Microsoftとの緊密な関係を「ビジネスリスク」として明示した。
これは単なる法的免責の定型文ではない。IPO前文書にリスクとして記載するということは、投資家向けに「この依存関係は将来の事業運営を制約しうる」と正式に認めたことを意味する。Microsoftはこれまで数百億ドル規模の資金をOpenAIに投じ、Azureインフラの独占的提供者として深く組み込まれている。
【背景】MicrosoftのOpenAIへの累計投資額は2019年の10億ドルを皮切りに、2023年に追加130億ドルを投じており、合計約140億ドル超とされる。契約の一環としてOpenAIのワークロードはAzureで優先的に処理され、MicrosoftはOpenAIの知的財産に対する一定の利用権を持つとされている。その関係を自ら「リスク」と呼ぶのは、依存からの脱却に向けた布石と読むのが自然だ。
背景には契約上の非対称性がある。OpenAIのモデルはAzure経由での提供が優先される構造になっており、推論コストの価格決定権や顧客との直接契約に制限がかかっている可能性が高い。OpenAIがAzureから離脱しようとした場合、推論インフラの再構築だけでなく、MicrosoftのエンタープライズむけCopilotとの競合問題も浮上する。リスク開示は現状の不満の表明であると同時に、IPO後に独自インフラへ投資する正当化でもある。
同時期に、OpenAIはプライベートエクイティ企業に対してAnthropicより有利な条件を提示しているという報道もある。資金調達の多様化とMicrosoftへの依存度低下は同じ方向を向いている。
この構造はAWSとBedrock上のAnthropicの関係にも同じものが見える。クラウド大手はAIスタートアップに資金とインフラを提供する代わりに、ディストリビューションチャネルを握る。スタートアップが独立しようとすると、インフラコストと顧客接点の両方で摩擦が生じる。
開発者への示唆
OpenAIのAPIを本番で使っているなら、Azure OpenAI Serviceと直接OpenAI APIの契約条件の違いを今すぐ確認すべきだ。OpenAIがMicrosoftとの関係を再交渉するプロセスで、SLAや価格体系が変動するリスクがある。
複数のLLMプロバイダーを切り替えられるアーキテクチャを今のうちに導入しておくべきだ。OpenAI対Microsoftの関係が変化する局面では、API互換性の破壊的変更や価格改定が突然起きる可能性がある。抽象化層がない構造は、その変化に対して無防備だ。
（ただし、その抽象化層の候補であるLiteLLM自体が今回のサプライチェーン攻撃の対象になっている。プロバイダー抽象化の選択肢を評価する際は、パッケージの公開パイプラインのセキュリティ体制も判断基準に加える必要がある。）
総括
今日の3件に共通するのは、LLMエコシステムの依存関係が攻撃面・制約面の両方でリスクに転化しつつあるという構造だ。
LiteLLM 1.82.8の .pth 埋め込みは、PyPIサプライチェーンへの信頼を直接突いた。1.82.8 をインストールしたことがある環境は今日中に全認証情報をローテートする。
Claude Codeのスクリーン操作はエージェントの操作範囲を「APIが存在するサービス」から「画面に表示されているもの全て」に拡張した。権限スコープの設計を先に固めないまま使い始めると、ログイン済み全サービスへのアクセス権をエージェントに渡すことになる。
OpenAIのMicrosoftリスク開示は、クラウド大手への依存がスタートアップの独立性を構造的に制約することを公式に認めたものだ。プロバイダー抽象化層を持たない本番システムは、この再交渉の余波に無防備だ。