社内AI基盤が“実際に攻撃される”時代へ｜LLMゲートウェイLiteLLMの脆弱性CVE-2026-42271がCISA悪用確認カタログ入り

結論：AI基盤の定番OSSが「理論上危ない」から「実際に攻撃されている」へ。LiteLLM利用企業は1.83.7以降への即時更新、全企業はAI基盤の脆弱性管理の担当を決めよ

2026年6月8日、米CISAは、LLMゲートウェイ LiteLLM のコマンドインジェクション脆弱性 CVE-2026-42271 を悪用確認済み脆弱性カタログ（KEV）に追加した。KEVは「実際に悪用が観測された脆弱性」だけを載せるリストであり、掲載は攻撃が現実に起きていることを意味する。米連邦行政機関には 6月22日までの対処が義務付けられた。

LiteLLM（BerriAI）は、複数LLMを統一APIで扱えるOSSゲートウェイで、社内RAGやAIエージェント基盤の「入口」として広く使われている。今回の脆弱性は 低権限の認証済みユーザーキーがあれば、プロキシのプロセス権限でホスト上の任意コマンドを実行できる（CVSS v3.1: 8.8 HIGH）というもので、修正版は 1.83.7以降 だ。

なお、CVE-2026-42271は単体ではキー保有が前提だが、2026年6月9日にHorizon3.aiが、Webフレームワーク Starlette のホスト検証バイパス（CVE-2026-48710）と連鎖させることで認証不要（unauthenticated）のRCEが成立する手法を公表している。この連鎖が成立する場合、正規キーを持たない攻撃者でも悪用し得る。LiteLLM 1.83.7以降への更新に加え、依存する Starlette側（1.0.1以降）の更新も併せて行うことが必須 だ。

この一件が示すのは個別製品の問題にとどまらない。「とりあえず立てた」社内AI基盤が、攻撃者にとって価値あるインフラとして標的化され始めたということだ。AI基盤にはAPIキー・社内文書・顧客データが集まる。管理の「担当」が決まっていない企業は、今日から決める必要がある。

押さえるべき1点：LiteLLMを使っているなら バージョン確認→1.83.7以降へ更新→当該エンドポイントの露出と不審ログの確認 を今日やる。使っていなくても、自社のAI基盤を構成するOSSの一覧と更新責任者を言えるか が問われている。

CVE-2026-42271の概要

侵入口がMCP（Model Context Protocol）サーバのテスト用エンドポイントである点は象徴的だ。エージェントとツールをつなぐために増設された機能が、そのまま攻撃面になった。AI基盤は「便利な接続」を増やすほど攻撃面が広がる——エージェント自身が標的になることを示したVaronisのフィッシング実証と地続きの構造である。

なぜ「社内向けだから安全」が通用しないのか

LiteLLMのようなゲートウェイは社内ネットワークやVPN内に置かれることが多く、「外部に公開していないから急がなくていい」と判断されがちだ。これは2つの理由で危うい。

第一に、この脆弱性は低権限の正規ユーザーキーで悪用できる。前提は「外部の侵入者」ではなく「キーを持つ誰か」だ。委託先、フィッシングで窃取されたキー、漏えいした検証用キー——内部キーの数だけ入口がある。

第二に、AI基盤はホストに価値が集中している。ゲートウェイのホストを取られれば、各LLMプロバイダのAPIキー、接続先システムの認証情報、ログに残るプロンプト（社内文書・顧客情報を含む）までまとめて危険にさらされる。任意コマンド実行はサーバ侵害そのものだ。

そして組織面の問題がある。社内AI基盤の多くはPoCの延長でAI推進室や開発チームが立てており、情シスの資産管理台帳・脆弱性管理プロセスに載っていないことが珍しくない。導入が止まっている企業の構造はRAGがなぜ導入されないのかで扱ったが、導入済みの企業には「管理されないまま動き続ける基盤」という逆側のリスクがある。

社内AI基盤の脆弱性管理チェックリスト

自社のAI基盤（RAG・エージェント・ゲートウェイ・ベクタDB等）を以下で点検してほしい。

1. 資産の棚卸し：AI基盤を構成するOSS・SaaS（ゲートウェイ、ベクタDB、オーケストレータ、MCPサーバ）を一覧化し、バージョンを記録しているか。
2. 更新責任者の明確化：各コンポーネントの脆弱性情報を追い、パッチを当てる担当が決まっているか（「AIチームか情シスか曖昧」が最頻の穴）。
3. KEV・アドバイザリの監視：CISA KEVや各OSSのアドバイザリを定常確認するプロセスがあるか。
4. キーの最小化と失効：利用キーを棚卸しし、不要キーの失効・権限最小化・有効期限設定ができているか。
5. ネットワーク分離：管理系・テスト系エンドポイントへの到達経路を必要な範囲に絞っているか。
6. ログと検知：基盤ホスト上の不審なプロセス実行・想定外の外部通信を検知できるか。
7. 侵害時の手順：侵害時に何のキーを失効し、どのデータの漏えいを想定するか、初動手順があるか。

依存OSS経由の侵害という構図はCI/CDでも繰り返されてきた（npmサプライチェーン攻撃とCI/CD依存関係セキュリティ）。原則は同じ——使っているものを把握し、更新の責任者を決め、悪用確認情報を監視するだ。6月の月例パッチも過去最大級の規模となっており（Microsoft 2026年6月パッチチューズデー）、AI基盤だけを特別扱いせず全社の脆弱性管理サイクルに組み込むことが重要だ。

よくある質問（FAQ）

Q. LiteLLMを使っているか分からない。どう確認すればいいか？ A. 開発チーム・AI推進部門に「複数のLLMを切り替えて使う仕組みの構成」を確認するのが早い。LiteLLMはRAGやチャットボット構築時にプロキシとして組み込まれることが多く、利用者自身が意識していない場合がある。コンテナ定義や依存関係を検索すれば特定できる。

Q. 社内ネットワーク内でしか使っていなくても更新が必要か？ A. 必要だ。本脆弱性は低権限の正規ユーザーキーで悪用できるため、社内利用者・委託先・窃取されたキーが入口になる。「内部限定だから後回し」は成立しない。

Q. 米行政機関向けの期限（6月22日）は日本企業に関係あるか？ A. 法的拘束力はないが、実務上の基準として強い意味を持つ。KEVの対処期限は「悪用が現実に起きており、この速度で対処すべき」というCISAの判断であり、国内企業も準じた優先度設定が妥当だ。

いつGXOに相談すべきか

• 社内にRAG・チャットボット・AIエージェント基盤があるが、構成OSSの一覧とバージョンを即答できない
• AI基盤の脆弱性情報を追い、パッチを当てる責任者が決まっていない
• AI基盤のキー管理・ネットワーク分離・ログ取得が構築時のまま見直されていない

GXOは、AI基盤を含む社内システムのセキュリティ診断で構成の棚卸しと脆弱性の洗い出しを行い、AI開発では脆弱性管理・キー管理を組み込んだ基盤設計を支援する。継続的なパッチ運用はセキュリティ顧問（リテイナー）で伴走する。→ 社内AI基盤のセキュリティ相談はこちら

関連記事

• AIエージェントは“釣られる”｜Varonis実証と導入前のセキュリティ設計
• RAGはなぜ導入されないのか｜導入格差と失敗の構造
• npmサプライチェーン攻撃とCI/CD依存関係セキュリティ
• Microsoft 2026年6月パッチチューズデー｜過去最大級の修正とBitLockerゼロデイ

参考資料

• NVD（米国国立標準技術研究所）CVE-2026-42271 https://nvd.nist.gov/vuln/detail/CVE-2026-42271
• CISA Known Exploited Vulnerabilities Catalog https://www.cisa.gov/known-exploited-vulnerabilities-catalog

本記事は2026年6月11日時点の公開情報をもとに作成。脆弱性の影響範囲・修正バージョン・悪用状況は更新される可能性があるため、対応にあたってはNVD・CISA・LiteLLM公式のアドバイザリの最新版を必ず確認すること。