AI推論サーバーのSSRF対策が急務に｜2026年5月30日版

2026年5月30日

AI推論サーバーのSSRF対策が急務に｜2026年5月30日版

AIの安全対策は、モデルの出力やプロンプトだけを見ていれば足りる段階を過ぎました。2026年5月30日時点で特に押さえたいのは、画像URLや外部ファイルを受け取るAI推論サーバーそのものが、クラウド内部へ届く攻撃経路になり得るという点です。

きっかけは、LLMデプロイ基盤「LMDeploy」のSSRF脆弱性 CVE-2026-33626 です。NVDは、0.12.3より前のLMDeployにおいて、vision-language moduleのload_image()が任意URLを検証せず取得し、クラウドメタデータサービスや内部ネットワークへアクセスされる可能性があると説明しています。

今日見るべき流れはシンプルです。

AI推論APIは、もはや「研究用の内向きツール」ではなく本番インフラになっている
マルチモーダルAIの画像URL取得機能は、SSRFの入口になりやすい
修正はライブラリアップデートだけでなく、認証、IAM、ネットワーク分離まで含めて見る必要がある
日本の開発チームも、RAG、画像入力、社内AI基盤の外部URL取得処理を棚卸しすべき局面にある

今日の重要ニュース早見表

重要度	分野	要点	日本の読者への影響
高	AI推論基盤	LMDeployのSSRF脆弱性 CVE-2026-33626 が確認され、NVDは0.12.3より前を影響範囲としている	オープンソース推論サーバーをクラウドGPUで動かす企業は、バージョンと公開範囲の確認が必要
高	クラウドセキュリティ	画像URL取得機能が、AWS Instance Metadata Serviceや内部サービスへの経路になり得る	AI基盤に付与したIAM権限が広いほど、侵害時の被害が大きくなる
中	運用設計	Cloud Security Allianceは、公開から悪用観測までの時間が「日」ではなく「時間」単位に縮んだと警告	AI関連OSSもWebフレームワーク並みのパッチSLAで扱う必要がある
中	開発プロセス	RAG、エージェント、画像入力など、外部URLをサーバー側で取りに行く設計が共通の確認対象になる	新規AI機能の設計レビューにSSRF観点を入れるべき

LMDeployの脆弱性で何が起きたか

LMDeployは、大規模言語モデルを圧縮、デプロイ、サービングするためのオープンソースツールです。問題になったのは、画像と言語を扱う機能で使われるURL取得処理でした。

NVDの説明では、0.12.3より前のバージョンで、lmdeploy/vl/utils.py内のload_image()が内部・プライベートIPアドレスを検証せず任意URLを取得していました。これにより、攻撃者が推論APIに到達できる場合、モデルサーバーに内部ネットワーク上のリソースへアクセスさせることが可能になります。

何が危ないのか

SSRFそのものは古い攻撃分類です。ただしAI推論サーバーでは、危険の出方が少し違います。

推論サーバーはGPUインスタンス上で動くことが多い
モデル、ログ、成果物へアクセスするため、クラウド権限を持っていることがある
画像入力やRAGのために、外部URLをサーバー側で取得する設計が入りやすい
研究・検証用途として立てた環境が、認証なしで社内ネットワークやインターネットから届く場合がある

つまり、単なる画像取得の不備が、クラウド認証情報や内部DB、管理画面へ近づく足場になります。モデルの精度とは別の層で、AI基盤の守り方が問われています。

なぜAI推論サーバーはSSRFに弱くなりやすいのか

マルチモーダルAIでは、ユーザーが画像URLを渡し、サーバーがその画像を取得してモデルに入力する構成がよくあります。これは開発者にとって便利です。クライアントが画像をアップロードしなくても、URLだけで処理できるからです。

しかし、サーバーがユーザー指定URLへアクセスする時点で、信頼境界が生まれます。

典型的な流れ

ユーザーが推論APIへ画像URLを渡す
推論サーバーがそのURLへHTTPリクエストを送る
取得した画像を前処理し、モデルに渡す
モデルがテキスト応答を返す

この2番目で、URLの宛先を制限しないと問題が起きます。外部画像のつもりが、127.0.0.1、プライベートIP、クラウドメタデータサービス、社内APIへ向かう可能性があるためです。

ここがポイント: AI推論サーバーは「モデルを動かす箱」ではなく、外部入力を受け取り、内部ネットワークへ通信できるアプリケーションサーバーとして扱う必要があります。

開発者と運用担当者が確認すべきこと

今回の論点は、LMDeploy利用者だけに閉じません。RAG、画像入力、AIエージェント、ドキュメント変換、URLクロールなど、AIアプリには「ユーザー入力を元にサーバーが外へ取りに行く」処理が多く入ります。

まず確認する項目

LMDeployを使っている場合、0.12.3以降へ更新しているか
推論APIがインターネット、VPN、社内共有ネットワークから到達可能になっていないか
API認証、mTLS、API Gatewayなどでアクセス制御しているか
推論サーバーのIAMロールが、必要以上にS3、Secrets Manager、DB、ログ基盤へ届かないか
169.254.169.254などのクラウドメタデータサービスへの到達を制限しているか
画像URL、RAG文書URL、エージェントのWeb取得機能に、プライベートIP拒否やDNS再解決対策が入っているか

アップデートだけでは足りない理由

脆弱な関数が修正されても、同じ設計パターンは別の場所に残ります。画像ローダーを直しても、PDF取得、HTMLスクレイピング、RAGのコネクタ、社内ツール呼び出しが同じ失敗をすると、別の入口ができます。

AI基盤では、次の3つをセットで見る必要があります。

入力検証: URL、ファイルパス、スキーム、リダイレクト先を制限する
外向き通信制御: 推論サーバーから内部IPやメタデータサービスへ出られないようにする
権限最小化: 侵害されても、盗まれる認証情報の権限を狭くする

日本の読者が見るべきポイント

日本企業でも、社内文書検索、画像問い合わせ、問い合わせ対応AI、開発支援AIのために、オープンソース推論サーバーやクラウドGPUを組み合わせる例は増えています。ここで重要なのは、AI機能を「アプリの一部」として扱うことです。

開発者

新しいAI機能を実装するときは、モデル選定だけでなく、外部URL取得の仕様をレビュー対象に入れるべきです。特に、ユーザーが渡したURLをサーバー側で取得する処理は、通常のWebアプリと同じSSRF対策が必要です。

企業利用者

SaaSや外部ベンダーにAI基盤を任せている場合でも、確認すべき点はあります。画像入力、URL読み込み、社内データ連携を使うサービスでは、推論基盤の認証、ネットワーク分離、クラウド権限管理が契約・セキュリティチェックの質問項目になります。

セキュリティ担当者

AI関連OSSを脆弱性管理の対象に入れているかが分かれ目です。WebサーバーやDBのCVEは追っていても、推論サーバー、ベクトルDB、RAGフレームワーク、エージェント実行基盤が棚卸しから漏れると、検知と修正が遅れます。

継続ウォッチ

次に見るべき点は、単発のCVEよりも運用ルールです。

LMDeploy v0.12.3以降の導入状況と、各配布経路での更新反映
vLLM、Ollama、TGI、RAGフレームワークなど、他の推論・AI基盤でのURL取得処理
クラウド各社がAI推論ワークロード向けに出すネットワーク分離やメタデータ保護の推奨設定
AI関連OSSを、既存のSCA、SBOM、CVE監視、パッチSLAにどう組み込むか

今日のまとめ

CVE-2026-33626の本質は、LMDeployだけの問題ではありません。マルチモーダルAIやRAGでは、サーバーがユーザー指定の外部リソースを取りに行く構成が自然に入り込みます。その便利さが、SSRFの入口にもなります。

今日の実務的な結論は明確です。AI推論サーバーは、モデル実行環境ではなく、認証、入力検証、ネットワーク制御、IAM最小化が必要な本番アプリケーションとして管理する必要があります。

まず見るべき場所は、派手なモデル発表ではありません。自社の推論APIがどこから届き、どこへ出ていけるのか。その経路図を1枚にできるかどうかが、次の確認点です。

参照リンク

よかったらシェアしてね！

URLをコピーしました！

URLをコピーしました！