社内で複数のLLM（大規模言語モデル）プロバイダーへのAPIリクエストをまとめて管理するために、LiteLLMのようなAIゲートウェイを導入している方に向けた内容です。ワークフロー基盤としてKestraを使っている運用担当の方にも関わる話です。
2026年9月2日、CISA（米国サイバーセキュリティ・インフラセキュリティ庁）が管理するKEVカタログ（既知の悪用済み脆弱性を集めたリスト）に新たに7件の脆弱性が追加されました。その中に、AIゲートウェイのLiteLLMとワークフローオーケストレーション基盤のKestraが含まれていました。VPN機器やWebフレームワークの脆弱性が並ぶこのリストに、AIインフラのコンポーネントが載ったのはこれが初めてです。
何が起きているか
LiteLLMには CVE-2026-59822 という認証不備の脆弱性が見つかりました。CVSS（脆弱性の深刻度を示す共通指標）で8.8という高いスコアが付いています。
Kestraにはさらに深刻な CVE-2026-49869 が見つかりました。OSコマンドインジェクション（外部から任意のOSコマンドを実行できてしまう不具合）で、CVSSスコアは満点の10.0です。
どちらも単なる社内ツールではありません。LiteLLMはモデルへのリクエストを振り分ける中継役として、Kestraはデータ処理のワークフローを組み立てる基盤として、多くの場合APIキーやDB認証情報を内部に保持しています。侵害されると、システム停止どころか認証情報そのものが漏えいするリスクがあります。
なぜ起きるか（原因の分解）
背景を段階的に見ていきます。
1つ目は、AIゲートウェイという役割の特殊性です。LiteLLMはOpenAI・Anthropic・Google等、複数のLLMプロバイダーのAPIを統一インターフェースで呼び出せるようにする中継ソフトウェアです。複数のアプリケーションから呼ばれる共有サービスとして構築されるため、社内の広い範囲、時にはインターネットからも到達可能な場所に置かれがちです。
2つ目は、認証の設計が後回しになりやすい点です。CVE-2026-59822は「不適切な認証」の脆弱性であり、本来チェックすべき呼び出し元の身元確認が甘くなっていたことが原因です。開発初期に動作確認を優先し、認証まわりの実装が追いついていないケースは珍しくありません。
3つ目は、ワークフロー基盤特有のリスクです。KestraはETL（データの抽出・変換・格納）やバッチ処理を組み立てるオーケストレーションツールで、タスクの中でシェルコマンドやスクリプトを実行する機能を持ちます。この「コマンドを実行できる」という設計そのものが、コマンドインジェクションの温床になります。CVSS 10.0という最高スコアは、認証を経ずに任意のOSコマンドを実行できてしまう組み合わせの深刻さを示しています。
4つ目は、これらのツールが比較的新しく、セキュリティ運用の対象として見落とされやすい点です。従来型のVPN機器やWebサーバーは資産棚卸しの定番項目ですが、AIゲートウェイやオーケストレーション基盤は「開発チームが独自に立てたツール」として、全社的な脆弱性管理の網から漏れている場合があります。
自分のプロジェクトが該当するか確認する方法
まず、自社でLiteLLMやKestraを使っているかどうかの棚卸しから始めます。
# LiteLLMのバージョン確認（pip管理の場合）
pip show litellm
# Dockerで動かしている場合はイメージのタグを確認
docker images | grep litellm
# Kestraのバージョン確認（Docker運用が一般的）
docker exec kestra_container kestra --versionバージョンが判明したら、CVE-2026-59822（LiteLLM）とCVE-2026-49869（Kestra）の修正版がリリースされているか、NVD（National Vulnerability Database）またはベンダーのGitHubリリースノートで確認します。
次に、そのインスタンスがインターネットに露出していないかを確認します。社内向けに立てたつもりでも、ロードバランサーの設定ミスやクラウドのセキュリティグループの設定漏れで、意図せず外部公開されているケースがあります。
# 自社のグローバルIPに対して該当ポートが外部から見えるか確認する例
nmap -p 4000,8080 自社のグローバルIPLiteLLMはデフォルトで4000番ポート、Kestraは管理UIとして8080番ポートを使うことが多いため、まずこの2つを確認対象にします。ポート番号は導入時の設定で変わるため、実際の設定ファイル（docker-compose.ymlやvalues.yamlなど）で確認するのが確実です。
外部からの見え方をより広く把握したい場合、ZoomEyeやShodanのようなインターネット資産検索エンジンで自社ドメイン・IPレンジを検索し、app=\"LiteLLM\"やapp=\"Kestra\"といったフィンガープリント（製品固有の特徴）に自社の資産が該当していないか照合する方法もあります。ある集計ではapp=\"LiteLLM\"が3万件超、app=\"Kestra\"が126件ヒットしたと報告されています。件数の差は導入形態の違いを反映しているだけで、Kestraの露出件数が少ないからといって危険度が低いわけではありません。
対策の手順
該当が確認できた場合、次の順序で対応します。
- パッチ適用: LiteLLM・Kestraとも修正版へのアップグレードを最優先にします。KEV掲載は「実際に悪用されている」証拠であり、任意対応ではなく緊急対応として扱います
- 外部公開の遮断: 業務上インターネット公開が不要なら、リバースプロキシやセキュリティグループでアクセス元を社内ネットワークやVPN経由に限定します
- APIキーのローテーション: 露出していた可能性がある場合、LiteLLM経由で使っていたLLMプロバイダーのAPIキー、DB接続情報を再発行します。使い回していたキーがあれば連鎖的に影響が及ぶため、関連する認証情報を洗い出します
- アイデンティティベースのアクセス制御: すべての呼び出し元を認証し、アクセスログを残す設定を有効にします。LiteLLMには仮想キー（Virtual Key）機能があり、利用者ごとに個別のキーを発行してログを追跡できます
- 資産管理への組み込み: AIゲートウェイやワークフロー基盤を、従来のサーバー・ミドルウェアと同じ脆弱性管理台帳・パッチ適用サイクルに載せます
まとめ
LiteLLMとKestraがKEVカタログに載ったことは、AIインフラが攻撃者にとって現実的な標的になった一つの節目です。
社内でこれらのツールを使っているなら、まずバージョン確認とポート露出のチェックから始めるのが現実的な一歩です。
CVSS 8.8のLiteLLMと10.0のKestra、どちらも猶予のある話ではありません。既存の脆弱性管理プロセスにAIインフラを組み込み、APIキーの棚卸しとローテーション手順を今のうちに整えておくことが、次に同種のCVEが出た時の対応速度を左右します。