もう、お決まりのシナリオだ。長年、サイバーセキュリティの世界は、ゼロデイ脆弱性が数ヶ月も潜伏し、ようやく野に放たれるのを待っていた。開示と悪用には、慎重な駆け引きがあるはずだった。しかし、CVE-2026-42208においては、その駆け引きはパニック映画さながらの疾走劇へと変貌した。オープンソースAIインフラの星、BerriAIのLiteLLMが、あっという間にやられたのだ。しかも、攻撃者は全く忍耐など持ち合わせていなかった。
これは、インターネットの片隅にあるような取るに足らない話ではない。LiteLLMはGitHubで驚異の4万5000スターを獲得している。OpenAIやAnthropicといった主要LLMプロバイダーの機密APIキーや設定を任せるに足る、開発者から信頼されるプロジェクトだ。そんなプロジェクトに、CVSSスコア9.3という深刻なSQLインジェクション脆弱性が発見されたら、一呼吸置くか、一時停止するか、と思いきや。甘い。36時間。脆弱性が開示されてから、それが実戦で悪用されるまでにかかった時間である。
脆弱性自体、後から思えば笑っちゃうほど単純だ。メンテナー自身がはっきりと述べている：「プロキシAPIキーチェックで使用されるデータベースクエリが、呼び出し元が提供するキー値を、単独のパラメータとして渡すのではなく、クエリテキストに混ぜてしまっていた」ということだ。つまり、どういうことか？ 特別に細工されたAuthorizationヘッダーを送れば、悪意のあるSQLコマンドをLiteLLMプロキシのデータベースクエリに直接送り込めるということになる。
認証されていない攻撃者は、あらゆるLLM APIルート（例えば、POST /chat/completions）に特別に細工されたAuthorizationヘッダーを送信し、プロキシのエラー処理パスを通じてこのクエリに到達させることができます。攻撃者はプロキシのデータベースからデータを読み取ることができ、場合によってはそれを改変することも可能になり、プロキシおよびそれが管理する認証情報への不正アクセスにつながる可能性があります。
そして、攻撃者が狙ったのは何だったか？ ユーザーテーブルではない。彼らが狙ったのは litellm_credentials.credential_values と litellm_config だ。これらは単なるランダムなデータベースエントリではない。OpenAIやAnthropicといったLLMプロバイダーのキー、中には月額5桁の利用上限を持つもの、コンソール管理権限、さらにはAWS BedrockのIAM認証情報といった、まさに宝箱だ。Sysdigが、その詳細を追求してくれたおかげで、ここでのデータベース抽出の成功は、典型的なWebアプリケーションのSQLインジェクションというより、クラウドアカウントの完全な侵害に匹敵すると指摘されている。もはや「正面玄関の鍵」どころか、「王国の鍵」の話なのだ。
真に恐ろしいのは、観測された運用上の洗練度だ。Sysdigは、攻撃者が単にランダムにあちこち探っているのではなく、テーブル名やカラム名を列挙していたと指摘している。これは、公開された概念実証（PoC）を必要としない、事前の偵察レベルを示唆している。公開されたアドバイザリと、オープンソースのスキーマ情報があれば、彼らにとっては攻撃を仕掛けるのに十分な情報だったということだ。これは力任せではない、外科手術のような攻撃なのだ。
しかも、LiteLLMが攻撃者の標的になるのはこれが初めてではない。わずか先月、TeamPCPハッキンググループによるサプライチェーン攻撃の標的となったばかりだ。これは孤立した事件というより、重要なAIインフラにおけるパターンとなりつつある。多くのスターを集め、開発者からの信頼を得ているこれらのプロジェクトは、広範な足がかりを得ようとする攻撃者にとって、格好のターゲットとなっている。
では、実際に金儲けをしているのは誰か？ 脆弱性ベンダー、ブラックマーケットのデータブローカー、そして盗まれた認証情報を自分たちの悪事のために転用する、陰謀渦巻くグループたちだ。その代償は？ LiteLLMを実行している組織にとっては、天文学的なデータ損失、認証情報の侵害、そしてインシデント対応と修復にかかる高額な費用というリスクだ。この迅速な悪用は、衝撃的な警告だ。脆弱性の開示から実際の悪用までの期間は、急速に縮小している。「パッチを当てるか滅びるか」という考え方から、「昨日までにパッチを当てろ」という必須事項へと移行しているのだ。
提案されている緩和策、つまり disable_error_logs: true の設定は、すぐにアップデートできない場合の「応急処置」に過ぎない。それは特定の穴を塞ぐが、根本的な構造的弱さを修正するものではない。真の解決策は、バージョン1.83.7-stableへのアップグレードだ。しかし、デプロイの途中で捕まったユーザーや、アップデートを遅らせたユーザーにとっては、その結果は深刻になりうる。CVE-2026-42208の迅速な悪用は、根本的な変化を浮き彫りにしている。AI時代において、攻撃の速度は加速しているのだ。もはや単なるソフトウェアの脆弱性ではなく、セキュリティアドバイザリのインクが乾く前に、重要なインフラが侵害される事態なのである。
開発者にとってなぜ重要なのか？
これはセキュリティチームだけの問題ではない。LiteLLM、あるいはそれに類するオープンソースAIインフラコンポーネントで開発を行っている開発者は、セキュリティ上の影響を強く意識する必要がある。これらのツールが機密キーの管理に不可欠であるということは、ツール自体の脆弱性が、クラウド認証情報やシークレットへの直接的なゲートウェイとなることを意味する。サードパーティライブラリ、特に機密データを扱うものを統合する際には、厳格なセキュリティ検証とプロアクティブなパッチ戦略が不可欠であることを痛感させられる。すべての依存関係を潜在的な攻撃ベクトルと見なすことは、パラノイアではない。今日の脅威ランドスケープにおける、健全な衛生管理なのだ。
LiteLLMはまだ信頼できるか？
LiteLLM自身も、それをデプロイした組織と同様に、ここでは被害者だ。脆弱性はバグであり、彼らはその後、それを修正した。本当の問題は、より広範なAIインフラのエコシステムにある。急速に人気を得て、重要な認証情報を扱うプロジェクトは、攻撃者の「磁石」となるだろう。信頼とは、バグが起こりうるか否かではなく、プロジェクトがどれだけ迅速に対応し、そのコミュニティがどれほどセキュリティを意識しているかということにかかっている。LiteLLMのメンテナーは迅速に問題に対処したが、悪用の速度は、たとえ意図は善意であっても、人気のあるオープンソースプロジェクトが攻撃者にとって高価値な標的となるという、より大きなトレンドの症状なのだ。開発者は引き続きLiteLLMを使用すべきだが、警戒と迅速なパッチ適用が「交渉の余地なし」であることを理解した上で、のことだ。
🧬 関連インサイト
よくある質問
LiteLLMとは何ですか？ LiteLLMは、さまざまなLLMプロバイダーとの対話を簡素化・標準化するオープンソースのAIゲートウェイです。プロキシとして機能し、開発者がモデルを切り替えたり、APIキーを管理したりするのを容易にします。
CVE-2026-42208とは何でしたか？ CVE-2026-42208は、LiteLLMのプロキシデータベースにおける深刻なSQLインジェクション脆弱性でした。これにより、認証されていない攻撃者は特定のヘッダーを細工して、LLMプロバイダーのAPIキーや認証情報などの機密データを改変または窃取することが可能になりました。
CVE-2026-42208はどのくらいの速さで悪用されましたか？ この脆弱性は、公開開示から約36時間後に実際に悪用され、新たに特定されたセキュリティ上の欠陥に対する脅威アクターの対応速度の速さが浮き彫りになりました。
