Multi Model Serverに認証不要の攻撃経路｜修正版なしで移行を推奨

AWSは、機械学習モデルを推論用に配信するオープンソースのMulti Model Server（MMS）について、コード実行につながる可能性とSSRFに関する2件の脆弱性を公表しました。対象は1.1.11以前の全リリースです。保守終了のため修正版の提供予定はなく、利用停止とサポートされる配信基盤への移行を勧めています。

告知の公開時刻は2026年10月23日10時30分PDT、日本時間では24日2時30分です。本稿は24日11時04分に公式告知とプロジェクト資料を確認しました。Webアプリから画像分類などの推論APIを呼ぶ構成では、その背後にMMSが残っていないかを確認してください。出典：AWS：Multi Model Serverの脆弱性と移行勧告 2026-148-AWS。

公開中の推論APIとは別に管理経路を調べる

CVE-2026-115812は、細工したモデルアーカイブの展開によって意図したディレクトリー外へファイルを書き込み、MMSプロセスの権限でコード実行につながる可能性がある問題です。CVE-2026-115813は、モデルのダウンロード経路を通じ、意図しない宛先へ要求を送らせる問題です。

AWSは、どちらも管理インターフェースが認証を要求しないと説明しています。ネットワークから到達できるアドレスで待ち受ける構成は特に注意が必要です。これは、すべてのWeb利用者が通常の推論要求だけで攻撃できるという説明ではありません。モデルを取得・登録する管理経路と、そこへ到達する条件を分けます。

旧来のAWS Labs：MMS Management API（旧資料）には、モデル登録、ワーカー数の変更、登録解除などが示されています。モデル登録はローカルのモデルアーカイブやHTTP(S)の取得先を扱います。管理APIは単なる状態確認画面ではなく、実行するモデルや取得元を変える操作を持つことが、今回の点検で重要です。

本稿で確認したAWS告知から、実環境での悪用や国内被害は確定できません。攻撃可能性の説明を、被害が発生したという報告へ置き換えないでください。また、AIモデルの配信基盤の脆弱性であり、攻撃者がAIで攻撃を自動化したことを確認した事例ではありません。

修正版を待つ案件ではない

AWS Labs：Multi Model Serverのアーカイブ済みリポジトリーには、2025年11月20日にアーカイブされ読み取り専用になったことが表示されています。過去の導入記事やDockerイメージが残っていても、現在の保守継続を示すものではありません。今回の対応では、配布物を再取得するだけで修正されると考えないことが出発点です。

本サイトの提案は、影響する稼働環境を見つける作業と、移行先を決める作業を並行して進めることです。Web側のリポジトリーだけでなく、推論サーバーのDockerfile、依存関係、デプロイ定義、独自イメージの元になった配布物を確認します。利用中のサービス名だけで、内部実装まで対象外と判断しないようにします。

一方、告知を根拠に、Amazon SageMakerの全サービスや全エンドポイントが影響すると断定することもできません。自分たちがMMSを含むコンテナや派生コードを運用しているかが確認点です。運用を委託している場合は、実装と保守責任を提供元へ照会します。

既定はlocalhostでもDocker設定は別

AWS Labs：MMSの詳細設定と設定ファイルの優先順位は、通常の推論APIを127.0.0.1:8080、管理APIを127.0.0.1:8081で待ち受ける既定値を説明する一方、Dockerイメージの既定値は異なると注意しています。AWS Labs：Docker向けconfig.propertiesでは、両方が0.0.0.0で待ち受ける設定を実際に確認できます。

inference_address=http://0.0.0.0:8080
management_address=http://0.0.0.0:8081

上記はアーカイブ済みリポジトリー内の設定を示すもので、推奨設定ではありません。0.0.0.0で待ち受けることだけでインターネット公開が確定するわけでもありません。コンテナのポート公開、ロードバランサー、リバースプロキシ、ネットワーク制御を重ねて確認し、誰が到達できるかを調べます。

AWS Labs：MMSのDocker利用手順（旧資料）には、管理用の8081番ポートをホストへ公開する起動例も残っています。これは過去の起動方法を知るための資料です。本記事は、その例を現在の本番導入手順として再実行することを勧めません。以前コピーした起動定義や検証用サーバーに残っていないかを探す手掛かりにしてください。

設定ファイルの場所と実際の起動条件を対応させる

設定資料では、MMS_CONFIG_FILE、--mms-config、作業ディレクトリーのconfig.properties、組み込みの既定値という順に設定ファイルを探します。編集したファイルが、起動プロセスに読み込まれているものかを確認してください。別のファイルを直して成功扱いにすると、待ち受けは変わらないまま残ります。

本サイトの点検票では、稼働単位ごとにイメージのダイジェスト、MMSの版、起動引数、設定ファイルの指定元、実際の待ち受け、許可された接続元を一組で残します。設定ファイルへ秘密情報が含まれる場合は、本文やチケットへそのまま貼り付けず、確認に必要な項目だけを記録します。

確認する層	集める情報	判断すること
配布物	MMSの版・イメージ・派生コード	本体が対象かと保守責任
起動設定	MMS_CONFIG_FILE・--mms-config	実際に読まれる設定
通信経路	待ち受け・ポート公開・転送先	管理操作へ到達する接続元
モデル供給	登録担当・保管場所・URL入力元	未承認のモデルや取得先が入らないか

暫定策は二つの構成で分ける

AWSは、推論用と管理用が別ポートの構成なら、管理側をループバックへ束縛し、外部から渡されたURLをダウンロード経路へ流さない暫定策を案内しています。ただし、SageMaker形式向けに同梱された構成では、両者が同じポートを使うため、その変更でモデル読み込みも止まると説明しています。

同一ポートの構成へ、別ポート用の変更だけを貼り付けないでください。AWSはこの構成で移行を優先し、当面は配信ポートへ到達できる呼び出し元を信頼できるものに制限するよう案内しています。どちらも保守終了したソフトウェアに修正を追加する措置ではありません。

本サイトの運用案では、制限変更の前に正規の呼び出し元とモデル読み込みの担当を確認します。変更後は、許可された推論要求と必要なモデル読み込みが動くこと、許可しない経路が遮断されることを別々に確認します。正常応答が一度返っただけでは、管理経路の閉鎖まで確認したことにはなりません。

コンテナ内の127.0.0.1は、そのコンテナが属するネットワーク名前空間のローカルを指します。外側のプロキシがどこから接続するかを把握せず、単にlocalhostへ変えるだけでは正規の管理処理を止めることがあります。実際の配置に合わせ、ネットワーク境界と運用手順を確認してください。

モデルの登録元と配信先を分離する

以下は設計を考えるための仮想例です。Web利用者の入力を受けるアプリが、要求ごとに任意のURLをMMSへ渡してモデルを登録しているとします。この構成では、通常の推論入力を扱う担当と、実行するモデルの配布を決める担当の境界が曖昧になります。今回の問題を調べる際には、このような中継処理の有無も確認対象です。

本サイトの提案は、Webからの推論要求には承認済みモデルの識別子を使い、モデルの取得・登録は限定された配布工程へ分けることです。すでにMMSを利用している場合、この設計変更だけで脆弱性を修正済みにすることはできません。暫定的に経路を減らしつつ、移行先でも同じ境界を維持するための整理です。

SSRFの一般的な設計確認は、AIのURL取得を内部ネットワークへの橋渡しにしない対策で扱っています。そちらは10月14日に確認した技術資料を基にした恒久対策の解説です。今回のMMSの影響版や暫定策は、本稿が参照するAWSの新しい告知で判断してください。

移行は推論結果だけでなく運用契約を比較する

移行先の製品名を決める前に、いまのAPIが受け取る入力形式、返すデータ、前処理と後処理、エラー、タイムアウト、モデルの読み込み方を整理します。MMSはモデルごとのハンドラーを持つため、同じモデルファイルを置くだけでWebアプリの応答形式まで同一になるとは仮定しません。

以下は本サイトが提案する移行の順序です。代表入力に対する期待結果と許容差を決め、検証用の配信先で確認し、Webアプリの接続先を段階的に切り替えます。精度・遅延・同時要求・メモリー使用量は自分たちの条件で測定します。本記事では移行先の性能試験を行っておらず、特定製品が速い・安いという比較はしていません。

切り戻しにも条件を付けます。障害時に、管理経路を広く公開した古いMMSへ無条件で戻す計画は避けます。必要なら機能を一時停止する条件や、暫定制限を維持した旧環境へ戻す判断担当を事前に決めます。旧コンテナの停止後は、自動再作成の定義や待機系に同じ配布物が残らないことも確認します。

侵害調査と移行完了を別に記録する

AWS Labs：MMSのログ設定（旧資料）には、アクセスログとモデルサーバー・ワーカー側のログが説明されています。旧資料のログ例や保存先は自環境と同一とは限りませんが、どこに要求履歴と処理の記録が残るかを確認する起点になります。

管理経路が意図せず公開されていた場合は、保存済みログとモデル登録履歴、配布物、プロセスや外向き通信の記録を保全し、正規作業の時刻と照合することを提案します。検査用の攻撃アーカイブを本番へ登録する必要はありません。ログが残っていない期間を、問題なしという判定で埋めないでください。

作業	完了の根拠
暫定的な到達制限	許可元の正常動作と許可外経路の遮断結果
モデル供給の制限	承認した配布物と登録担当の記録
移行先の検証	Webアプリの入出力・負荷・障害時の確認結果
MMSの撤去	稼働・待機・自動再作成の対象から除外
侵害有無の調査	調べた記録の範囲と未確認期間

今回の判断は「更新を待つ」から「到達性を下げながら撤去・移行する」へ切り替えることです。公開情報の定期確認に基づく記事であり、常時監視や個別環境の被害確認を実施したものではありません。CISAのページは取得拒否で照合できておらず、悪用状況を同機関の一覧で確認済みとはしていません。