NVIDIA Dynamoに15件脆弱性。社内LLM基盤の確認急げ

NVIDIAのオープンソースLLM推論スタック「NVIDIA Dynamo」に15件の脆弱性が公表されました。CRITICAL 1件、HIGH 10件を含み、認証不要でリモートから攻撃可能な深刻なものがあります。GitHubから導入するためOSのパッケージ管理や自動更新に乗らないこのミドルウェアは、情シスの資産台帳に載っていないことも多く、影響の有無を確認するための棚卸しが急務です。

• 15件の脆弱性の全体像と、CVEごとに異なる修正バージョンの確認ポイント
• 特にCRITICALとSSRF群のリスクの実際
• 資産台帳に載らないAI推論ミドルウェアの把握と対策の進め方

何が起きたのか

NVIDIAは2026年8月4日、オープンソースのデータセンター規模LLM推論スタック「NVIDIA Dynamo」に関するセキュリティ速報「Security Bulletin: NVIDIA Dynamo – August 2026」を公開しました。これはNVIDIA PSIRTが2025年10月1日以降に開始した、GitHub上でのMarkdown/CSAF/CVE形式による公開の一環です。

今回公表された脆弱性は計15件で、深刻度の内訳はCRITICAL 1件、HIGH 10件、MEDIUM 4件です。対象はLinux上で動作するDynamoで、GitHubリポジトリ「ai-dynamo/dynamo」からcloneまたは更新して導入する環境が該当します。OSのパッケージ管理システムやベンダーの自動更新機能には乗らないため、利用環境でのバージョン管理と手動での適用対応が必要です。

影響を受ける環境と修正バージョン

15件すべてを塞ぐには、修正版の確認が不可欠です。CVEごとに修正済みバージョンが異なり、v1.1.1への更新だけでは不十分です。特にCVE-2026-47620とCVE-2026-47622はv1.3.0で初めて修正されるため、15件すべてに対応するには最低でもv1.3.0への更新が必要となります。

なお、CVE-2026-24254については、公開されている説明では「境界外書き込み」とされていますが、割り当てられているCWEはCWE-288（代替パスまたは代替チャネルを用いた認証回避）となっており、現時点で詳細な技術的根拠は限定的です。いずれにせよ、CVSS 9.8のCRITICALとして扱い、露出を最小化する判断が必要です。

現時点で悪用の事実は確認されていませんが、NVIDIAも「多様な導入環境の平均に基づくもので、個々の環境の実際のリスクを表すとは限らない」と述べており、自社環境での再評価が前提となります。

特に注意すべき脆弱性

認証不要でリモートから届くCRITICAL（CVE-2026-24254）

CVE-2026-24254はCVSS 9.8で、ベクトルはCVSS:3.1/AV:N/AC:L/PR:N/UI:Nです。これは認証不要、利用者の操作不要でネットワーク越しに到達可能であり、成功すればコード実行や権限昇格、データ改ざん、サービス拒否、情報漏えいに至る可能性があることを示しています。社内ネットワークに設置したつもりであっても、VPNや踏み台経由で外部から届く可能性がある場合は、最優先で対応を検討してください。

SSRFとパストラバーサルの集中（CVE-2026-47612〜47618）

15件のうち7件が、外部リソースの取得や参照にまつわる脆弱性に集中しています。内訳はSSRF（CWE-918）が6件、パストラバーサル（CWE-22）が1件です。これはDynamoのマルチモーダル対応が、利用者が指定したURLや画像をサーバ側が取得する設計であることに起因します。特にクラウド上のGPUノードは、メタデータサービスへの到達や強い権限のロールを抱えていることが多く、SSRFの実害は「情報漏えい」の一言では済まない場合があります。

CVE-2026-47617はDNSリバインディングを用いたSSRFで、宛先URLをホスト名でチェックするだけの対策ではすり抜けられる点も注意が必要です。こうした攻撃手順については、LangflowのSSRF脆弱性、AI開発ツールの守り方でも解説しています。

サンプルコードに潜む脆弱性（CVE-2026-47619）

CVE-2026-47619はexamplesやrecipesに含まれる問題です。AI推進部門が検証環境やPoCとして動作させた構成を、そのまま本番に流用していないか確認が必要です。サンプルコードは「動作確認用」として軽視されがちですが、こうした箇所が攻撃の足がかりになることは少なくありません。

現場目線の課題：資産台帳に載らないミドルウェア

この手のソフトウェアは、情シスの資産台帳やCMDBに載っていないことが少なくありません。GitHubからcloneして構築するため、WSUSやOSのパッケージ管理、ベンダーの自動更新にも乗らず、「誰が、どのノードに、いつ入れたか」が分からないまま動作しているのが実情です。

AI推進部門や研究部門が自前で立てた推論基盤に対し、情シスが後から口を出しづらいという空気も現場にはあります。しかし、認証不要でリモートから到達可能なCVSS 9.8の脆弱性が存在する以上、線引きの議論より先に「どこに何が動いているか」を突き止める方が早いでしょう。

限られた人員で増え続けるAI関連ミドルウェアまで網羅するのは正直に言って負担が大きいものの、Dynamoのような推論スタックはもはやApacheやnginxと同じく「常時外部入力を受けるミドルウェア」であり、定期パッチの対象に組み込む段階に来ています。確認の入口は難しくありません。GPUノード上のPython環境やコンテナイメージのタグ、Helmチャートの参照先を洗い、バージョンを控えるところから始められます。社内AI基盤の棚卸しの重要性については、SGLangに未修正のRCE脆弱性、社内LLM基盤に警戒でも取り上げています。

情シスはどうすべきか

まずは自社環境にNVIDIA Dynamoが導入されているか、どのバージョンが動作しているかを確認してください。特にCVSSとは？脆弱性の深刻度を評価する仕組みと使い方で解説している通り、CVSSベクトルのAV:N（ネットワーク到達可能）とPR:N（権限不要）は、攻撃のハードルが極めて低いことを意味します。

パッチ適用においては、15件すべてに対応するにはv1.3.0が必要です。ただし、DynamoはAI推論の稼働中に更新すると影響が大きいため、メンテナンスウィンドウの確保と動作確認の計画を立ててください。即座の更新が難しい場合は、該当するエンドポイントのネットワーク分離やWAFによる制限、マルチモーダル入力の一時的な制限などで露出を減らすことを検討します。

また、NeMoに深刻な脆弱性CVE-2026-24228 AIの盲点でも指摘したように、NVIDIAのAIスタックは脆弱性の公表が相次いでおり、継続的なバージョン管理プロセスの構築が不可欠です。脆弱性管理とは？プロセスと情シスの進め方を解説を参照いただき、資産把握からパッチ適用、再発防止までの一連の流れを整備してください。

対策の基本となる考え方については、IPA 中小企業の情報セキュリティ対策ガイドラインや、インシデント対応の準備としてIPA セキュリティインシデント対応 机上演習教材も活用ください。地道なユーザ教育と啓発も、攻撃の入口を減らす上で欠かせません。

まとめ

• NVIDIA Dynamoに15件の脆弱性が公表され、CRITICAL 1件を含み認証不要でリモートから攻撃可能なものがある。15件すべてを塞ぐにはv1.3.0への更新が必要である。
• マルチモーダル対応に起因するSSRFやパストラバーサルが複数存在し、クラウド上のGPUノードでは実害が大きくなりうる。
• GitHubから導入するため資産台帳に載りにくいAI推論ミドルウェアだが、バージョンの棚卸しと定期パッチ運用を情シスが含めて管理する段階に来ている。

出典

• NVIDIA PSIRT「Security Bulletin: NVIDIA Dynamo – August 2026」（2026年8月4日）
• NVIDIA Product Security
• ai-dynamo/dynamo（GitHub）
• Security NEXT「『NVIDIA Dynamo』に『クリティカル』含む複数脆弱性 – 修正版が公開」