NVIDIA NemoClaw/OpenShellに脆弱性18件

NVIDIAは2026年8月25日、AIエージェントを安全に動かすためのオープンソース基盤「NemoClaw」と「OpenShell」について、合計18件の脆弱性を修正するセキュリティブレティンを公開しました。最も深刻な2件はCVSS 3.1基本値 9.9（クリティカル） で、サンドボックスからの脱出（CVE-2026-65093）と、サンドボックス払い出しAPIの入力制限不備（CVE-2026-65083）です。AIエージェントを閉じ込めるための箱そのものに、箱を破る穴が空いていた形になります。

「うちはNVIDIAのAI基盤など導入していない」と思った方こそ、いったん手を止めてください。これらは調達を通らず、開発者が自分の端末に1行のコマンドで入れられるツールです。資産管理台帳には載りません。

この記事でわかること

  • NemoClaw / OpenShell とは何をするもので、誰がどこに入れているのか
  • 18件の脆弱性のうち、情シスが特に見るべき4件の中身
  • 自社の端末・クラスタに入っているかを確認する具体的な方法
  • 「AIエージェントの安全な実行環境」を導入する際に持つべき視点

NemoClaw・OpenShellとは何者か

OpenShellとは、自律的に動くAIエージェントを隔離された環境（サンドボックス）で実行するための、NVIDIA製のオープンソース実行基盤です。エージェントがどのファイルを読めるか、どこに通信してよいかを宣言的なYAMLポリシーで制御し、資格情報の持ち出しや無制限の外部通信を防ぐことを目的としています。

NemoClawは、そのOpenShellの上でAIコーディングエージェントを動かすための「参照スタック」です。NVIDIA公式ドキュメントの整理では、OpenShellが実行環境・サンドボックスのライフサイクル・ネットワーク・ファイルシステム・プロセスポリシーを受け持ち、NemoClawはその上位でCLI・プラグイン・推論ルーティングの設定を提供します。公式READMEによれば、対応エージェントは OpenClaw（既定）、Hermes、LangChain Deep Agents Code です。

誰が、どこに入れているのか

導入するのは主に開発者・データサイエンティスト個人です。想定される導入先は次の系統で、いずれも情シスの資産管理から漏れやすい経路です。

  • 個人の作業端末（Linux / macOS / Windows の WSL 2）：OpenShell公式READMEは、インストール手順として curl -LsSf https://raw.githubusercontent.com/NVIDIA/OpenShell/main/install.sh | sh というワンライナーを案内しています。承認プロセスも社内配布パッケージも介在しません。
  • NemoClaw経由での「気づかない同梱」：NVIDIA公式ドキュメントは「NemoClaw sits above OpenShell」と明記し、NemoClawがOpenShellのAPI・CLIを呼び出してサンドボックスを作成・設定すると説明しています。つまりNemoClawを入れた端末には、OpenShellも一緒に入ります。OpenShellを個別に導入した記憶がなくても、対象になり得ます。
  • Kubernetesクラスタ：OpenShellはHelmチャート（oci://ghcr.io/nvidia/openshell/helm-chart）でゲートウェイをクラスタへ配置する経路も持ちます。README上は「実験的（Experimental）」の位置づけですが、PoCで立てたまま残っている検証クラスタは要確認です。
  • Pythonプロジェクトの依存：PyPIに openshell パッケージも存在します。ただしREADMEによればこれはPython SDKのみで、CLI本体は含みません。

なお、OpenShellのREADMEにはプロジェクトステータスとして alpha のバッジが掲げられています。ここは判断材料として押さえておきたいところです。

何が起きたのか：18件の内訳

NVIDIAのブレティン（2026年8月25日、リビジョン1.0.0）が扱うのは18件のCVEです。深刻度の内訳はクリティカル2件、高13件、中3件。CVSSは3.1基準です。特に押さえるべき4件を挙げます。

CVE 対象 内容 CVSS / 深刻度 CWE
CVE-2026-65093 OpenShell（Linux） サンドボックス脱出 9.9 / クリティカル CWE-427
CVE-2026-65083 OpenShell（Linux） サンドボックス払い出しAPIで禁止入力リストが不完全 9.9 / クリティカル CWE-184
CVE-2026-65091 OpenShell（全プラットフォーム） 悪意あるゲートウェイによるOSコマンドインジェクション 8.8 / 高 CWE-78
CVE-2026-65105 NemoClaw（Linux） 推論サーバ設定の不備で、未認証のまま推論サービスへアクセス可能 8.1 / 高 CWE-306

上位2件のCVSSベクタは AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H です。注目すべきは S:C（Scope Changed）。脆弱なコンポーネントの権限境界を越えて影響が及ぶことを意味し、まさに「サンドボックスの外側に手が届く」という評価になっています。必要な権限は PR:L（低い権限）で、利用者の操作（UI:N）も不要です。

残りの14件はどんな傾向か

ブレティンの一覧を眺めると、傾向がはっきりしています。OSコマンドインジェクション（CWE-78）が5件と最多で、NemoClawのCLI、ステータス／ログ用プラグインコマンド、NIM管理コンポーネント、Telegramブリッジ、そしてOpenShellのサンドボックス実行ハンドラといった箇所に分散しています。ほかに、インストール処理での未検証コードの実行（CWE-494、CVE-2026-65081）、インストールスクリプトでの完全性チェックなしのダウンロード（CVE-2026-65097）、デプロイ処理での不適切な証明書検証（CWE-295、CVE-2026-65084）が並びます。

要するに、「エージェントを閉じ込めるロジック」よりも、その手前の導入・運用まわりのコード（インストーラ、CLI、プラグイン、外部連携）に穴が集中しているということです。ブレティンの注記には「これらの脆弱性は外部から報告された（found externally）」とあり、謝辞欄には社外の研究者名が並びます。

なぜCVE-2026-65105が特に注目されたのか

18件のうち、報道で最も取り上げられたのはCVE-2026-65105です。NVIDIAの公式説明は「推論サーバのセットアップに脆弱性があり、リモートの攻撃者が認証なしで推論サービスにアクセスできる可能性がある」という記述にとどまりますが、報告者（ブレティンの謝辞欄には Oasis Security の Markus Halvorsen、Elad Luz と記載）による公開情報では、より具体的な攻撃経路が示されています。

複数の技術メディアの報道によれば、NemoClawがローカル推論エンジンOllamaを OLLAMA_HOST=0.0.0.0:11434 で起動していたため、全ネットワークインターフェイスでAPIが露出し、Ollama自身が持つHostヘッダ検証も効かない状態になっていたとされます。そのうえでDNSリバインディングを併用すると、利用者が悪意あるWebページを開くだけで、ブラウザのJavaScript経由でローカルの推論APIに到達できるという筋書きです。さらに /api/create エンドポイントでモデルのチャットテンプレートを書き換えると、注入した指示が以降の会話にも残り続けた、と報告されています。

この攻撃経路の詳細部分は研究者・報道ベースの情報であり、NVIDIA公式ブレティンの記述には含まれていない点は区別しておいてください。ただしCVSSベクタが AV:A（隣接ネットワーク）である事実は公式情報であり、同一セグメントに攻撃者の足がかりがあれば届くという前提は公式にも裏づけられています。

自社に入っているかをどう確認するか

資産管理台帳に載らないツールなので、台帳を眺めても答えは出ません。端末とクラスタを直接見るのが確実です。

  • CLIの有無：開発端末で openshell / nemoclaw コマンドが通るか。バージョンはCLIのバージョン表示で確認します。
  • 修正版に達しているか：OpenShellは 0 から 0.0.33 が影響を受け、v0.0.34 で修正されています（CVE-2026-65093 / 65092 / 65091 / 65086 / 65085 / 65083 が対象）。NemoClawはCVEごとに影響範囲が異なり、CVE-2026-65105は 0 から 0.0.25 が対象で 0.0.25 が更新版、CVE-2026-65097 と CVE-2026-65081 は 0.0.21、CVE-2026-65090 / 65088 / 65082 は 0.0.17 が更新版です。細かいので、実務的には最新版へ更新したうえでブレティンの対応表と突き合わせるのが現実的です。
  • 推論サーバの露出：Ollamaの既定ポートである TCP 11434 が、ループバック以外で待ち受けていないかを確認します。Linuxなら ss -lntp の出力で待ち受けアドレスが 0.0.0.0 になっていないかを見ます。ここは、たとえNemoClawを使っていなくても、ローカルLLMを触っている端末全般で確認する価値があります。
  • Kubernetes：helm list -A でopenshellのリリースが残っていないか。
  • Pythonの依存：requirements.txt / pyproject.toml / ロックファイルに openshell が入っていないか。

更新自体はGitHubリポジトリからのcloneまたはupdateで行う、というのがNVIDIAの案内です。パッケージ配布システム経由の一斉配信ではないため、「配信すれば終わり」ではなく、入れた本人に更新してもらう必要がある点が運用上のポイントになります。

現場目線の課題：守るための箱が、増えた面になる

正直なところ、この件でいちばん気が重いのは脆弱性そのものではありません。影響範囲を把握できないことです。

エンドポイント管理製品でインストール済みアプリケーションを吸い上げても、curl | sh でホームディレクトリ配下に置かれたバイナリは、素直には一覧に出てきません。開発部門の端末は業務上の裁量が大きく、情シスが細部まで目を届かせるのは現実的に難しい。結局「入っているかどうかを聞いて回る」という、いちばん原始的な方法が速い、という場面が実際にあります。

もうひとつ引っかかるのは、これが「AIエージェントを安全にするために導入したもの」だという点です。導入した担当者は、間違いなく善意でセキュリティを向上させようとしています。それを情シスが「脆弱性があるので確認させてください」と追いかける構図は、対立を生みやすい。ここで「勝手に入れるな」と正面から言うと、次からは黙って入れられるだけです。「入れるのは構わない。ただし入れたら教えてほしい／更新の責任は入れた人が持つ」という着地に持っていくほうが、実務的には機能しやすいと感じます。

そして技術的な教訓として、サンドボックス・仮想化・エージェント実行基盤といった「隔離するための仕組み」は、それ自体が高い権限で動く新しい攻撃面になるという古典が、今回もそのまま当てはまりました。18件が隔離ロジックそのものよりインストーラ・CLI・外部連携ブリッジに集中していたのは象徴的です。新しいレイヤーを1枚足すたびに、守る対象も1枚増えます。

情シスはどうすべきか

個別製品の対応は上記のとおりですが、より本質的なのは「生成AI・AIエージェントを業務でどう使わせるか」のルール整備です。ここは自前で長いチェックリストを作るより、公的機関の枠組みに沿うほうが確実で、社内説明にも使えます。

加えて、地道ですが効くのはユーザ教育・啓発です。今回のCVE-2026-65105のように「Webページを開いただけで手元のAIが汚染される」タイプの攻撃は、利用者に危機感が湧きにくい。ローカルで動かすAIも外部に口を開けた1つのサービスである、という感覚を共有できるかどうかが分かれ目になります。

中長期の視点：AIエージェント基盤は「新しいミドルウェア」として扱う

AIエージェントの実行基盤は、これから業務システムの下層に定着していく可能性が高い領域です。であれば、扱いはWebサーバやアプリケーションサーバと同じ「ミドルウェア」に寄せるのが素直でしょう。つまり、バージョンを台帳に載せ、ベンダーのセキュリティ情報を購読し、パッチ適用のSLAを決める。今回のOpenShellが alpha ステータスであることを踏まえれば、当面は破壊的変更と脆弱性修正が続く前提で運用計画を立てるのが安全です。

また、NVIDIAは製品セキュリティのページで、2026年10月1日以降はセキュリティブレティンをMarkdownおよびCSAF形式でGitHub上に公開する方針を示しています。CSAFは機械可読な脆弱性情報の標準形式なので、脆弱性管理ツールへの取り込みを自動化する余地があります。手作業での情報収集に限界を感じている場合は、追っておく価値があります。

まとめ

  1. NVIDIAはNemoClaw / OpenShellの脆弱性18件を2026年8月25日に公表。最大はCVSS 9.9のサンドボックス脱出（CVE-2026-65093）と払い出しAPIの入力制限不備（CVE-2026-65083）で、いずれもScope Changed＝隔離境界を越える評価です。
  2. OpenShellは0〜0.0.33が影響、v0.0.34で修正。NemoClawはCVEごとに影響範囲が異なるため、最新版へ更新したうえでブレティンの表と突き合わせます。まずは openshell / nemoclaw コマンドの有無と、TCP 11434の待ち受けアドレスを確認してください。
  3. 本質的な課題は「台帳に載らない導入経路」。ワンライナーで入るツールを禁止で押さえ込むのは難しく、申告と更新責任をセットにした運用に落とすほうが現実的です。AIエージェント基盤は新しいミドルウェアとして資産管理に組み込みましょう。

関連記事

出典

タイトルとURLをコピーしました