`trust_remote_code=False` が効かない、vLLM 3連目のRCE CVE-2026-4944

明示的に --trust-remote-code=False を指定して防御していたつもりが、vLLM 内部のモデル実装ファイルでハードコードされた trust_remote_code=True がサイレントに上書きしていました。悪意ある HuggingFace リポジトリを指定するだけで、運用者が拒否したはずのリモートコードが推論サーバ上で実行されます。

2026年3月、vLLM プロジェクトに対して GitHub Security Advisory GHSA-7972-pg2x-xr59（CVE-2026-4944 / 別名 CVE-2026-27893）が発行されました。CVSS 3.0 は 8.8、攻撃ベクトルは AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H。影響範囲は vLLM 0.10.1 〜 0.17.x、修正は 0.18.0。PR #36192 は Red Hat の Russell Bryant 氏が 2026年3月6日にマージし、3月20日に vLLM 0.18.0 として公開されています。

本件は vLLM における trust_remote_code バイパスの3件目です。CVE-2025-66448（auto_map 経由）、CVE-2026-22807（registry.py の動的モジュールロード）に続き、今回はモデル実装ファイル個別でのハードコード上書きという、同じ「セキュリティ境界がモデル個別実装に分散している」構造に起因する穴が露出した形です。

何が起きたのか — 早見表

本件の論点を1枚で整理します。「何が踏むと壊れる組み合わせか」を最初に把握するためのテーブルです。

特異な点は、運用者が --trust-remote-code=False（または VLLM_TRUST_REMOTE_CODE=0）を明示的に設定していても、上の2ファイルがロードされる経路に入った瞬間にハードコードの True が効いてしまうことです。ログにも警告は出ません。RAXE Labs のアドバイザリはこのオーバーライドを「silent」と明記しています。

そもそも trust_remote_code とは何か

HuggingFace Transformers の世界では、モデルリポジトリに modeling_*.py や tokenization_*.py という Python ファイルを同梱することができます。新しいアーキテクチャをライブラリ本体のリリースを待たずに配布するための仕組みです。

問題は、これらのファイルが AutoModel.from_pretrained() や AutoConfig.from_pretrained() を呼んだ瞬間に import 経由でそのまま実行される という点です。実体としては、HuggingFace Hub から落としてきた他人のPythonコードを exec() しているのと変わりません。

この危険を運用者がオプトインで受け入れるためのフラグが trust_remote_code です。HuggingFaceは 公式ドキュメントで「trust_remote_code=True はインターネットから取得した未検証コードを exec() する行為とほぼ同等のリスクを持つ」と明言しています。したがって vLLM の運用者が --trust-remote-code=False を選ぶというのは、「リモートからのPython実行を絶対に許さない」という明確なセキュリティ意思表示です。

CVE-2026-4944 の悪質さは、この意思表示が握りつぶされるところにあります。それも、警告ログも例外も出さずに、特定モデルを指定した瞬間だけ。

攻撃者像と狙い — 誰が、何のために、何を持っていくのか

3週間ごとに同じ型の trust_remote_code バイパスが3件続いている事実は、これが偶発ではなく特定の攻撃者層にとって極めて価値の高い攻撃面であることを示しています。vLLM を抱えた本番環境を念頭に、誰がこの穴を欲しがり、踏ませた瞬間に何が手元に残るのかを攻撃者の視点から具体的に並べます。

この穴を実際に踏ませたい層は、中国系・東欧系のオフェンシブAI研究集団、HuggingFaceとPyPIに偽装パッケージを撒く生成AIサプライチェーン業者、自社モデルの推論API顧客リストを欲しがるライバルAIスタートアップ、そして社内LLM基盤の管理権限を狙う元従業員といった具体的な人間たちです。彼らがvLLMの推論サーバから持ち出したいのは、運用者の OpenAI APIキーや Anthropic APIキー、HuggingFace のプライベートトークン、AWS Bedrock のクロスアカウントロール、社内のRAGに食わせている顧客契約書や設計図面PDFのキャッシュ、ファインチューニング前の社内対話ログ、そしてGPUクラスタの常駐SSH秘密鍵です。この CVE-2026-4944 を踏ませた瞬間、上記すべてが推論プロセスのメモリと環境変数からそのまま相手の手元に渡ります。

攻撃の事前偵察は驚くほど簡単です。HuggingFace Hub のトップダウンロード数を見れば誰が Nemotron-VL や Kimi-K2.5 を本番投入しているかが推測でき、企業の技術ブログや求人票には「vLLMで推論基盤を運用」「Nemotron-VL を社内QAボットに採用」と書かれています。そこに タイポスクワッティング（公式リポジトリ名 nvidia/nemotron-vl-8b に対する nvidia-ai/nemotron-vl-8b など微差のレポ）、放棄リポジトリの買収、社内DSへの偽推奨（「最新版はこっちです」とSlackに貼る）といった経路で、運用者を悪意あるモデルパスへ誘導するだけで十分です。一度ロードされれば、攻撃者は推論コンテナ内のPythonを完全に握り、そこから内部ネットワークへの横展開、モデル重みの吸い出し、長期常駐用のcronやsystemdユニット仕込みまで、好きな順番で進められます。

CVSS 8.8 という数字は推論サーバ1台を奪われる技術的な深刻度にすぎません。AI推論基盤を運用する企業にとって本当に持っていかれるのは、推論キャッシュに残ったままの顧客データ、再学習のためにかき集めた数十TBの社内ナレッジ、そして「自社のAIは安全に運用されている」と顧客に説明してきた信頼そのものです。とりわけ、明示的に --trust-remote-code=False を設定して防御していたチームほど、「うちは大丈夫」と答えた直後に踏まれる構造になっている点が、この CVE のもっとも厄介な側面です。

攻撃の届く先 — 3層境界表

運用パターン別に「この CVE で何が奪われ、何までは奪われないか」を整理しておきます。読者の自分ごと判定を最速化するためのテーブルです。

「OSのrootそのものは取られない」を強調する読者向けの注意点を1つ。vLLMがroot権限で起動されているケースは依然として多く、特にコンテナの中で USER root のまま走らせている社内基盤では、上記の「届かないもの」は事実上届きます。NVIDIAの公式コンテナイメージや一部のチュートリアルでデフォルトが root になっている点も影響しています。

CVE-2026-4944 の中身 — どこに True がハードコードされていたか

問題のコードは、vLLM のモデル実装ファイル2か所に存在しました。PR #36192 の差分から正確な行を引用します。

CVE-2026-4944 (1/2): nemotron_vl.py:430

NVIDIA の Nemotron-VL 系モデルの vision_model サブコンポーネントをロードする箇所で、trust_remote_code=True が直書きされていました。

vision_model = AutoModel.from_config(
    config.vision_config,
    trust_remote_code=True,  # ← ここがハードコード
)

vision_model = AutoModel.from_config(
    config.vision_config,
    trust_remote_code=self.config.model_config.trust_remote_code,
)

運用者が起動時に --trust-remote-code=False を渡しても、本ファイルが入ったコードパスに到達した瞬間に True が固定値で渡され、サブコンポーネントの modeling_*.py がリモートから取得・実行されます。

CVE-2026-4944 (2/2): kimi_k25.py:177

Moonshot AI の Kimi-K2.5 系モデルの image_processor をロードする箇所で、同じパターンが繰り返されていました。

image_processor = cached_get_image_processor(
    self.ctx.model_config.model,
    trust_remote_code=True,  # ← こちらもハードコード
)

image_processor = cached_get_image_processor(
    self.ctx.model_config.model,
    trust_remote_code=self.ctx.model_config.trust_remote_code,
)

修正は self.config.model_config.trust_remote_code（または self.ctx.model_config.trust_remote_code）で運用者の設定値を伝播させる、というシンプルな置換です。PR descriptionにも「ハードコードされた True を運用者の設定値に置き換え、サブコンポーネントロードでも --trust-remote-code=False のセキュリティオプトアウトを尊重するようにする」と明記されています。

本来この2行は最初から書かれるべき設定伝播でした。なぜ書かれていなかったのか — 後述の「3連目」という構造的問題の話につながります。

3連目のRCEという系譜

vLLM における trust_remote_code バイパスは、これが3件目です。RAXE Labs のアドバイザリは「3rd trust_remote_code bypass in vLLM」と明記しており、構造的問題であることを強調しています。3件の系譜を時系列でカード化します。

← スワイプで移動

RAXE Labs が指摘する構造的問題は、vLLM のモデル実装が個別ファイルに分散しており、それぞれが独立して trust_remote_code の伝播を管理する設計になっている点です。中央集権的なトラストバウンダリ強制機構がないため、新規モデルを追加するエンジニアが trust_remote_code=True をうっかり書いた瞬間、それが本番運用者の False 設定を握りつぶす穴になる、というパターンが繰り返されています。

同じ穴がLMDeployにも — CVE-2026-46432

2026年5月21日、上海AI研究所傘下の InternLM がメンテナンスする推論サーバ LMDeploy でも、同じ「trust_remote_code=True ハードコード」が報告されました（CVE-2026-46432）。

LMDeploy の場合は 0.13.0 未満の全バージョンが影響を受け、修正は PR #4511 として 0.13.0 にマージされています。vLLMと同じく「攻撃者がモデルパスを制御できれば、HuggingFaceリポジトリ経由でリモートPythonが走る」という挙動です。

vLLM・LMDeploy・SGLang といった主要なLLM推論サーバはいずれも HuggingFace Transformers をラップする形でモデルロード処理を実装しており、trust_remote_code の伝播設計を間違える地雷がそれぞれの実装ファイルに散らばっている可能性があります。OSSのモデル配信が当たり前になったいま、推論サーバ側の「設定伝播の正しさ」を継続的に監査する仕組みは、ベクター検索やRAG運用のチームにとっても外せない論点です。サプライチェーン視点で網を張る場合はOSSサプライチェーンスキャナーのまとめ記事もあわせて参照してください。

今すぐやる5つの対応

vLLMで本番推論を回している運用者は、以下を順に進めてください。1番目は緊急、2〜5番目は今週中に。

特に4番目（egress制限）は、本CVEに限らず推論サーバ全般の防御線として効きます。HuggingFace から落としたリモートコードが exec() された場合でも、外向き通信が絞られていれば、攻撃者が C2 サーバへコールバックする経路、AWS Instance Metadata Service v1（IMDSv1）から一時クレデンシャルを盗み出す経路、内部ネットワークへ横展開する経路の全てが塞がれます。

締め — 「OFFにしていたつもり」が一番危ない

CVE-2026-4944 が示しているのは、「セキュリティオプションを明示的に False にしていれば安心」という直感が、現代の複雑なAIインフラでは通用しないという事実です。OSSのライブラリは多数のサブコンポーネントから構成されており、ユーザーが渡した False がそのすべてに正しく伝播するとは限りません。今回の3連目は、それを3度目のシグナルとして突きつけてきた事案です。

運用者にできる最善は、(a) 推論サーバの依存をピンしバージョンを上げ続けること、(b) HuggingFace から落とすモデルの modeling_*.py を事前に読むこと、(c) コンテナのegressを絞ること、の3点に尽きます。「--trust-remote-code=False を渡したから大丈夫」という前提を持たないこと自体が、当面の最良の防御策です。

vLLM 0.18.0 への更新がまだの環境は、公式リリースノートを確認のうえ、今週中の適用を強く推奨します。

参照元

• ▸ NVD - CVE-2026-4944（2026年5月29日公開）
• ▸ GitHub Security Advisory - GHSA-7972-pg2x-xr59（2026年3月26日）
• ▸ vLLM PR #36192 - Respect user trust_remote_code setting in NemotronVL and KimiK25（2026年3月6日マージ）
• ▸ RAXE Labs - RAXE-2026-044: vLLM Hardcoded trust_remote_code Bypass（2026年3月27日）
• ▸ SentinelOne Vulnerability Database - CVE-2025-66448
• ▸ SentinelOne Vulnerability Database - CVE-2026-22807
• ▸ GitLab Advisory Database - CVE-2026-46432 (LMDeploy)（2026年5月21日）
• ▸ vLLM Releases - 0.18.0（2026年3月20日リリース）
• ▸ HuggingFace Transformers - Security Overview