LiteLLMにSQLi脆弱性（CVE-2026-42208、CVSS 9.3）公開、36時間で野放し攻撃を観測

「AIプロキシのLiteLLMに脆弱性が出たって、自社のAPIキーは大丈夫？」
「公開からたった36時間で攻撃が始まったって本当か？」

チップス

ボス、LiteLLMっていうAIプロキシでSQLインジェクション脆弱性が出たって聞いたでしゅ。CVSSが9.3で、しかも公開直後に攻撃されたとか……

ボス

そうだ。LLMプロバイダのAPIキーが集まる位置にあるソフトだから、攻撃者の標的としてうってつけだ。情報窃取の被害が即金銭損失につながりやすい。

LLM活用の中核に置かれるプロキシソフト「LiteLLM」に、未認証で攻撃可能なSQLインジェクション脆弱性が公開されました。
本記事では、CVE-2026-42208の仕組み、悪用までの早さ、そして導入企業が取るべき緊急対応の手順をまとめてお届けします。

OpenAI・Anthropic・Bedrock等のAPIキーをLiteLLMで一元管理している組織には、取り急ぎの対応が必要な内容です。
最後まで読めば、なにを優先すべきかがすぐに把握できます。

CVE-2026-42208の概要

脆弱性の発生経緯と、攻撃者の動きを順に整理します。

プロキシAPIキー検証クエリの欠陥

本脆弱性は、プロキシAPIキー検証時のデータベースクエリでパラメータ化が行われず、呼び出し元の入力値がクエリ本体に混入することに起因します。
そのため、未認証の攻撃者が細工したAuthorizationヘッダを送るだけで、バックエンドDBへのSQL注入が成立します。
BerriAI/LiteLLMのバージョン1.81.16から1.83.6が対象で、修正版1.83.7-stableは2026年4月19日に公開されています。

36時間で実環境攻撃に発展

GitHubアドバイザリの公開から26時間後の2026年4月26日16:17(UTC)に、初回の悪用が観測されました。
攻撃者は認証情報や設定が格納されたテーブルを集中的に探索しており、ユーザーやチームのテーブルには手を出していません。
ターゲットを絞った動きから、システム構造を熟知した者の関与が示唆されます。

チップス

26時間で攻撃が始まるなんて、パッチを当てる前に侵入されていてもおかしくないんでしゅ……

ボス

そうだ。「公開直後に対応する前提」で運用を組まないと間に合わない時代だな。

日本企業が取るべき対応

緊急対応とAPIキーの保護を中心に、優先順位を整理します。

即時パッチとAPIキーの再発行

第一優先は1.83.7-stableへのアップデートで、LiteLLMをコンテナ運用している場合はイメージタグの再ビルドも忘れず行ってください。
すでに対象バージョンを公開ネットワークで稼働させていた場合、APIキーの流出を前提として全プロバイダのキー再発行とログ精査が必要です。
パッチ適用が即時に難しい環境では、設定でdisable_error_logs: trueを有効化し、脆弱なクエリ経路を遮断する暫定策があります。

侵害痕跡の確認ポイント

侵害有無の判断材料としては、認証情報テーブルや設定テーブルへの不審なアクセスログが重要です。
具体的には、Authorizationヘッダに不自然な記号が含まれるリクエストや、想定外のSELECT文がDBログに残っていないかを確認します。
あわせて、LLMプロバイダ側の利用課金にも異常な伸びがないか必ず突き合わせましょう。

まとめ

LiteLLMのCVE-2026-42208は、LLM活用が進む組織にとって認証情報を直接狙われる典型的な事例です。
パラメータ化クエリの基本が崩れると、AIプロキシのような中継ソフトでも従来型のSQLiが致命傷になることを思い出させます。
修正適用と同時にAPIキーの再発行までやり切るのが、安全側に倒した運用です。
引用元:The Hacker News – LiteLLM CVE-2026-42208 SQL Injection