AI開発者に広く使われているLLMプロキシ「LiteLLM」に、認証なしで悪用できるSQLインジェクション脆弱性（CVE-2026-42208）が発見された。脆弱性公開からわずか36時間で実際の攻撃が確認されたことをクラウドセキュリティ企業Sysdigが報告しており、該当バージョンを使用しているチームは速やかな対応が求められる。

LiteLLMとは — AIゲートウェイが抱える「巨大な鍵束」

LiteLLMはOpenAI・Anthropic・AWS Bedrockなど複数のLLMプロバイダーを単一のAPIで利用できるオープンソースのプロキシ／SDKミドルウェアだ。GitHub上で45,000スターを超えるほど開発者に支持されており、複数のAIモデルを使い分けるプラットフォームや社内LLMゲートウェイとして広く採用されている。

重要なのは、LiteLLMが一元管理する情報の種類だ。仮想APIキー・マスターキー・各プロバイダーのクレデンシャル・環境変数・設定ファイルなど、AIインフラ全体の「鍵束」がひとつのデータベースに集約されている。この構造が今回の脆弱性を特に危険なものにしている。

CVE-2026-42208の仕組み

この脆弱性はLiteLLMのプロキシAPIキー検証ステップで発生するSQLインジェクション（SQLi）だ。攻撃者は認証なしで、細工したAuthorization: BearerヘッダーをLLM APIの任意のルートに送信するだけで、プロキシのデータベースを読み取り・改ざんできてしまう。

根本原因はシンプルだ。SQLクエリを文字列連結で組み立てていた箇所が存在したことによる。修正版（バージョン1.83.7）ではパラメータ化クエリへの置き換えが行われており、これはSQLiに対する古典的かつ確実な対策だ。

攻撃者は「お宝」の場所を知っていた

Sysdigの分析によれば、攻撃者は2段階のアプローチを取った。

第1フェーズ: /chat/completionsエンドポイントに悪意あるペイロードを含むリクエストを送信し、データベース構造を探索。APIキー・プロバイダークレデンシャル・環境データを格納するテーブルを特定した。

第2フェーズ: IPアドレスを切り替え（検出回避と思われる）、フェーズ1で特定したテーブル名を使ってより少数の精密なペイロードで情報を抽出した。

Sysdigが「攻撃者は秘密が保管されている場所に真っ直ぐ向かった」と表現するほど、ランダムな探索ではなく、意図的な標的型攻撃だった。

今すぐ行うべき対応

優先度1：アップグレード LiteLLM 1.83.7以降へのアップグレードが最優先。litellm --versionで現在のバージョンを即確認できる。

優先度2：アップグレードが難しい場合のワークアラウンド general_settingsにdisable_error_logs: trueを設定することで、脆弱なクエリへ悪意ある入力が到達する経路をブロックできる。

優先度3：侵害を前提とした対処 インターネットに公開されたLiteLLMインスタンスが脆弱なバージョンを使用していた場合、すでに侵害された可能性があるとして扱うべきだ。仮想APIキー・マスターキー・すべてのプロバイダークレデンシャルを即座にローテーションすること。

実務への影響 — 日本のエンジニア・IT管理者への警告

複数のAIサービスを一元管理するゲートウェイ的な構成は、コスト最適化や管理効率の面から合理的な選択だ。しかし、その「一元管理」という特性が、一点突破で全社のAIクレデンシャルが流出するリスクを生む。

確認すべき点は以下の通りだ：

  • LiteLLMをインターネットに直接公開していないか — ゲートウェイは内部ネットワーク経由のアクセスに限定すべきだ
  • 使用バージョンが1.83.7未満でないか — 即確認を
  • 格納しているクレデンシャルが必要最小限か — ゲートウェイに「なんでも突っ込んでおく」構成は危険
  • クレデンシャルのローテーション体制が整っているか — 漏洩時に即座に対応できる仕組みが重要

また、LiteLLMは最近PyPI経由のサプライチェーン攻撃（TeamPCP）も受けており、インストール済みパッケージのバージョン確認も合わせて推奨される。

筆者の見解

今回の脆弱性で改めて浮き彫りになったのは、「Non-Human Identity（NHI）管理」の重要性だ。AIシステムが扱うAPIキーやプロバイダークレデンシャルはまさにNHIであり、これを適切に管理できるかどうかが今後の自動化・AI活用の成否を左右する。逆に言えば、NHI管理が甘いと、今回のような「全部持っていかれる」リスクを常に抱えることになる。

SQLインジェクションという古典的な攻撃手法が、最先端のAIゲートウェイで今なお発生するという事実は、AIブームに乗った高速開発の「影」を示している。脆弱性公開から36時間という速度での悪用も、AIツール関連のセキュリティ情報は攻撃者も真剣に追っていることの証拠だ。

LLMゲートウェイを「便利な統合レイヤー」として導入する際、そのゲートウェイ自体が単一障害点かつ攻撃の最高価値標的になることを忘れてはいけない。「今動いているから大丈夫」で放置するのではなく、定期的なバージョン確認とクレデンシャルローテーションの仕組みを整えることが、今日のAI活用における基本的なセキュリティ衛生だと言えるだろう。

出典: この記事は Hackers are exploiting a critical LiteLLM pre-auth SQLi flaw の内容をもとに、筆者の見解を加えて独自に執筆したものです。