NeMo Agent Toolkitの脆弱性CVE-2026-65145：1.9.0への更新と2026年末EOL前の移行判断

NVIDIAは2026年10月27日、AIエージェントの開発フレームワークであるNeMo Agent Toolkitの脆弱性2件を公表しました。CVSS 10.0の認証の欠如 CVE-2026-65145 と、SQLインジェクションの CVE-2026-65151 です。修正版の1.9.0は9月10日にPyPIへ出ています。一方でNVIDIAは10月にこのツールキットを非推奨とし、2026年末で提供を終えると告知しました。この記事では、分割されたパッケージの版を照合するスクリプト、サーバーの待ち受けの確認、更新手順、そしてEOLを踏まえた移行の判断を、実装の目線で整理します。内容は2026年11月7日時点の公開情報にもとづきます。

まとめ：NeMo Agent Toolkitは1.9.0へ上げ、年末EOLまでに移行先を決める

CVE-2026-65145は1.0から1.8.0までのすべての版が対象で、ネットワーク越しに認証なしで突ける評価です。CVE-2026-65151は1.4から1.6が対象です。どちらも1.9.0で塞がるため、手元の版が1.9.0未満なら今週中に上げます。

見落としやすいのは、1.5.0以降のツールキットが「nvidia-nat-core」「nvidia-nat-mcp」などの複数パッケージに分かれている点です。本体の版だけを見て安心せず、入っている関連パッケージを全部照合します。

もう1つの判断は移行です。1.9.0への更新は今回の穴を塞ぐだけで、2027年以降に見つかる脆弱性の修正は期待できません。本番で動いているエージェントがあるなら、更新と同時に移行先と期限を決めてください。社外に公開しているAPIやMCPサーバーを含めて点検の範囲を決めたい場合は、脆弱性診断・セキュリティ診断で対象を洗い出すと抜けが出にくくなります。

NVIDIA勧告5912：CVE-2026-65145とCVE-2026-65151の対象

NeMo Agent Toolkit（パッケージ名は nvidia-nat、コマンド名は nat）は、LangChainやCrewAIなどで作ったエージェントをYAMLの設定で組み合わせ、REST APIやMCPサーバーとして公開するためのPythonのフレームワークです。NeMoの名を持つ製品群の中での位置づけはNVIDIA NeMo Frameworkの分割後の構成で整理しています。

認証の欠如CVE-2026-65145：CVSS 10.0と1.0〜1.8.0の影響範囲

NVIDIAのセキュリティ勧告5912によると、CVE-2026-65145はCWE-306（重要な機能に対する認証の欠如）に当たり、悪用されるとコード実行、権限昇格、データ改ざん、サービス停止、情報漏えいにつながります。ベクトルは AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H で、ネットワーク越し、認証なし、利用者の操作なしで突けるという評価です。影響の範囲がツールキットの外へ及ぶ（S:C）ため、点数は上限の10.0になります。

勧告は、どのエンドポイントや機能で認証が欠けていたのかを示していません。CVEレコードの記述も勧告と同じ1文です。そのため本記事では、ツールキットが外部からの要求を受け付ける入口（REST API、MCPサーバー、A2Aサーバー）をすべて確認の対象にしています。各指標の読み方はCVSSv3のスコアの目安と計算式で確認できます。

SQLインジェクションCVE-2026-65151：1.4〜1.6とVanna連携の関係

CVE-2026-65151はCWE-89（SQLインジェクション）で、CVSSは8.4です。こちらは攻撃元が AV:L（ローカル）と評価されており、ネットワークから直接届く65145とは性質が違います。影響版は1.4から1.6、修正版は1.7.0です。

勧告は該当するコンポーネントを書いていませんが、版の範囲には符合する事実があります。自然文からSQLを作る連携パッケージ nvidia-nat-vanna はPR #974で加わり、PyPIには1.4.0から1.6.0までしか出ていません。1.7.0ではPR #1926でこのパッケージごと削除されました。PRの説明には、元のVannaのリポジトリがアーカイブされ、Vanna側のSQLインジェクションCVE-2026-4229が未修正のままだと書かれています。CVE-2026-65151がこの連携を指すとは断定できません。それでもText-to-SQLを使っていた環境は、優先して確認する対象です。SQLインジェクションの仕組みそのものはSQLインジェクションの攻撃例と対策で解説しています。

KEV未登録・NVD分析待ち・国内注意喚起なしの11月7日時点

2026年11月7日の確認では、CISAのKEVカタログ（2026.11.06版）に2件とも載っていません。NVDはどちらも分析待ち（Awaiting Analysis）で、JPCERT/CCの2026年の注意喚起一覧にもNVIDIA製品の項目はありません。勧告の注記は「外部からの報告で見つかった」で、2件とも50words.comの研究者が発見者に挙がり、65145にはTrendAIのZero Day Initiative経由の報告者も併記されています。

悪用の報告が無いことは、急がなくてよい理由にはなりません。修正版が勧告より7週間早く出ていたため、1.8.0と1.9.0の差分を読めば穴の場所を推測できる状態です。

影響確認：nvidia-nat系の分割パッケージと待ち受けアドレスを調べる手順

確認は2点です。入っているパッケージの版と、起動しているサーバーがどのアドレスで待ち受けているかを見ます。

分割パッケージを全部照合するPythonスクリプトとCIで落とす使い方

ツールキットは1.5.0でパッケージの構成が変わり、本体の nvidia-nat は nvidia-nat-core と、nvidia-nat-mcp・nvidia-nat-langchain などの関連パッケージを束ねるだけのものになりました。PyPIのnvidia-nat 1.9.0は関連パッケージを同じ1.9.0に固定していますが、core や mcp だけを個別に入れた環境ではそれぞれの版を見る必要があります。1.5.0の移行ガイドで廃止された移行用パッケージ aiqtoolkit が残っていれば、nvidia-nat へ入れ替えます。

次のスクリプトは、実行したPython環境に入っている関連パッケージをすべて拾い、2件の影響版に当たるかを判定します。

import re
import sys
from importlib.metadata import distributions

# NVIDIA Security Bulletin 5912（2026-10-27）の修正版
FIX_AUTH = (1, 9, 0)   # CVE-2026-65145 認証の欠如：1.0〜1.8.0 が影響
FIX_SQLI = (1, 7, 0)   # CVE-2026-65151 SQLインジェクション：1.4〜1.6 が影響
OLD_NAMES = ("aiqtoolkit",)  # 1.5.0 で廃止された移行用パッケージ


def parse(v):
    m = re.match(r"(\d+)\.(\d+)\.(\d+)", v)
    return tuple(int(x) for x in m.groups()) if m else None


found = bad = 0
for d in distributions():
    name = (d.metadata["Name"] or "").lower().replace("_", "-")
    if not (name.startswith("nvidia-nat") or name.split("-")[0] in OLD_NAMES):
        continue
    found += 1
    ver = parse(d.version)
    notes = []
    if name.split("-")[0] in OLD_NAMES:
        notes.append("旧パッケージ名：nvidia-nat 1.9.0 へ移行")
    elif ver is None:
        notes.append("版を読めない（手で確認）")
    else:
        if ver < FIX_AUTH:
            notes.append("CVE-2026-65145 影響版（1.9.0 以上へ）")
        if (1, 4, 0) <= ver < FIX_SQLI:
            notes.append("CVE-2026-65151 影響版（1.7.0 以上へ）")
    if name == "nvidia-nat-vanna":
        notes.append("1.7.0 で削除されたText-to-SQL連携：依存から外す")
    bad += bool(notes)
    print(f"{name:28} {d.version:12} {' ／ '.join(notes) or '修正版以上'}")

if not found:
    print("NeMo Agent Toolkit のパッケージは見つかりませんでした")
sys.exit(1 if bad else 0)  # CIで使うときは影響版があれば失敗させる

対象の仮想環境で python nat_vuln_check.py と実行します。2026年11月7日に、PyPIから取り出した各版のメタデータで動作を確かめました。nvidia-nat-core 1.8.0は65145の影響版、nvidia-nat-mcp 1.5.0とnvidia-nat-vanna 1.6.0は2件とも影響版、aiqtoolkit 1.4.3は旧名と判定され、終了コードは1でした。1.9.0の組では「修正版以上」と出て0で終わります。コンテナのビルドやCIの最後に置けば、古い版のままのイメージを出荷前に止められます。

nat serve・nat mcp serve：8000・9901・9902番の待受確認

ツールキットのサーバーは、既定ではどれも localhost で待ち受けます。既定のポートは、REST APIを出す nat serve が8000番、nat mcp serve が9901番、FastMCPを使う nat fastmcp server 系が9902番、A2Aサーバーが10000番です。問題になるのは、コンテナで動かすために --host 0.0.0.0 を付けて起動した構成です。公式のMCPサーバーの手順書にも、この指定の例が載っています。

# Linux：ツールキットの既定ポートで、どのアドレスに待ち受けているかを見る
ss -ltnp | grep -E ':(8000|9901|9902|10000)\b'

# 0.0.0.0 や [::] で待ち受けている行があれば、外から届く前提で扱う
# 起動コマンドの確認（コンテナならエントリポイントも見る）
ps -eo pid,args | grep -E 'nat (serve|mcp serve|start|a2a serve|fastmcp)'

ローカルアドレスの欄が 127.0.0.1 なら、同じ機械の中からしか届きません。0.0.0.0 や [::] なら、ファイアウォールやセキュリティグループの設定次第で外から届きます。nat serve はSwaggerの画面を /docs に出すため、届く状態なら、そのURLを開けばAPIの一覧まで見えてしまいます。

1.9.0への更新：依存の固定と、Vanna連携を外すときの手順と注意点

GitHubのv1.9.0リリースは2026年9月10日付けで、勧告もGitHubのリポジトリから1.9.0以降を取得するよう求めています。リリースノートには認証まわりの変更が複数ありますが、どれがCVEの修正かは書かれていません。版を上げることだけを対策と考えます。

pipとuvでnvidia-natを1.9.0へ上げるコマンドと廃止パッケージの置き換え

1.9.0はPython 3.11以上、3.14未満を要求します。3.10以前で動かしている環境は、先にPythonを上げる必要があります。

# 使っている追加機能（extras）を付けたまま 1.9.0 に固定する
pip install -U "nvidia-nat[mcp,langchain]==1.9.0"

# uv で管理しているプロジェクト
uv add "nvidia-nat[mcp,langchain]==1.9.0"

# 廃止された移行用パッケージと、1.7.0 で削除された連携を外す
pip uninstall -y aiqtoolkit nvidia-nat-vanna

# 更新後にもう一度照合する
python nat_vuln_check.py

extrasの mcp や langchain は例です。pip freeze の結果から、いま入っている nvidia-nat-○○ の名前を拾って同じものを付けてください。requirements.txt や pyproject.toml に nvidia-nat-core==1.8.0 のような個別の固定が残っていると、本体を上げても古い版が戻ります。依存ファイルを検索して、関連パッケージの固定を全部1.9.0へそろえます。

Text-to-SQLのnvidia-nat-vanna削除後の代替構成と連携方法

1.6.0までのText-to-SQLの関数（text2sql と execute_db_query）を設定に書いていた場合、1.7.0以降では連携パッケージ自体が無いため、その設定のままでは動きません。この機能はツールキットの中では復活しないので、自社のコードでSQL生成の関数を書き直すことになります。

書き直すときに守る点は2つです。生成したSQLを実行するDBユーザーには参照の権限だけを与え、更新や削除をできないようにします。もう1つは、実行してよいテーブルと文の種類を、LLMの出力とは別の場所で検査することです。設計の考え方はText-to-SQLの仕組みと安全な実装にまとめています。

更新までの暫定策：認証の無いサーバーを外へ出さない構成と侵害の確認

勧告は回避策を示していません。ここで挙げるのは、更新が済むまでの被害を小さくするための私たちの判断で、穴そのものは塞がりません。

0.0.0.0で起動しない設定と、認証付きリバースプロキシの後ろに置く構成

v1.9.0の手順書には、nat mcp serve が今もサーバー側の認証を持たないという記載があります。本番では信頼できるネットワークの内側か、HTTPSで認証するリバースプロキシ（OAuth2・JWT・mTLS）の後ろで動かし、認証なしで0.0.0.0や公開IPに出さないよう求めています。SSEのトランスポートは認証に対応しないため、用途は開発用に限るという記載です。トランスポートの違いはStreamable HTTPとSSEの違いで確認できます。

FastMCPのランタイムを使う場合は、FastMCPサーバーの手順書にあるとおり server_auth でOAuth2のトークン検証をかけられます。ただし同じ手順書では、FastMCP3はベータという理由から、本番での利用は非推奨です。FastMCPそのものはFastMCPでMCPサーバーを作る手順で解説しています。

私たちの判断は単純です。外から届く状態で動いているサーバーがあれば、更新より先に --host 127.0.0.1 で起動し直すか、ネットワークの設定で入口を閉じます。認証付きのプロキシを用意できるまでは、外部への公開を再開しません。

エージェントが持つAPIキーとDB権限の棚卸しと入れ替えの判断

CVE-2026-65145の影響にコード実行が入っている以上、外から届く状態で1.8.0以前を動かしていたなら、エージェントのプロセスが読めた秘密情報は漏れた前提で考えます。公式のセキュリティ上の注意事項も、APIキーやトークンがログや外部の宛先へ渡る危険を挙げています。

• LLMのAPIキー（NVIDIA_API_KEY、OpenAIやAnthropicのキーなど）と、環境変数や設定ファイルに置いた外部サービスのトークン
• ツールに渡したDBの接続情報と、そのユーザーが持つ書き込み・削除の権限
• MCPクライアントとして外部のMCPサーバーへつなぐときのOAuth2のクライアントシークレット
• 観測用のログに残ったプロンプトと応答（個人情報や社外秘が混ざりうる）

localhostでしか待ち受けていなかったことを確認できた環境では、入れ替えまではしません。外から届いていた環境では、利用量の急な増加をLLMの管理画面で確かめたうえで、キーを入れ替えます。APIの入口で入れておく防御はAPI不正アクセス対策の実装手順で整理しています。個人データに触れられた疑いが出た場合は、個人情報保護委員会への報告義務と期限も並行して確認してください。

2026年末EOLを踏まえたNeMo Relay・Fabric・Helixへの移行判断

NVIDIAは2026年10月23日、リポジトリのREADMEとドキュメントに非推奨の告知を加えました。NeMo Agent Toolkitは2026年10月で非推奨となり、2026年末にEOLを迎えます。告知はEOLの前に移行を済ませるよう勧めています。

用途別に分かれた後継3製品と、ツールキットの機能との対応関係

後継は1つの製品ではありません。ツールキットが1つで担っていた役割が、3つのリポジトリに分かれています。

3つとも2026年3月から6月に作られた新しいリポジトリで、ツールキットの設定ファイルをそのまま読める移行ツールは告知に書かれていません。nat serve でREST APIを出していた部分は、どの後継にもそのままの形では無いと考えて設計し直します。

1.9.0で止めて移行するか、別のフレームワークへ移るかを分ける条件

判断の分かれ目は、ツールキットの中で何を使っているかです。

NVIDIAのNIMやNemotronを中心に組み、観測や評価の機能まで使っているなら、Relay・Fabric・Helixへ移ります。同じ会社の後継なので、モデルの呼び出しや評価の考え方を引き継ぎやすいからです。

反対に、ツールキットをLangChainやCrewAIのエージェントをAPIとして出すための薄い外枠としてだけ使っているなら、後継3製品へは移りません。元のフレームワークの公開手段や、自社で書くFastAPIのサーバーに置き換えたほうが、依存が減って後の更新も追いやすくなります。

どちらを選ぶ場合でも、2027年1月以降も1.9.0のまま動かし続ける選択は採りません。EOL後に新しい脆弱性が見つかっても、修正版が出る保証が無いためです。年内に移行が終わらない見込みなら、少なくともサーバーを社内ネットワークの内側に閉じ、外へ出している入口を残さないようにします。

NeMo Agent Toolkitの脆弱性対応で出やすい質問と回答の要点

CVE-2026-65145と65151の対応を進める中で出てきやすい疑問に、公開されている一次情報の範囲で答えます。

localhostでしか動かしていない開発環境も更新が必要ですか？

必要です。CVE-2026-65145はネットワーク越しの攻撃と評価されていますが、同じ機械で動くほかのプロセスや、ブラウザを経由した要求から届く可能性は否定できません。加えて、開発環境の依存ファイルは本番のイメージにそのまま引き継がれがちです。開発の段階で1.9.0へそろえておけば、古い版を本番へ持ち込む事故も防げます。

1.9.0のあとにEOLまでの修正版はさらに出ますか？

11月7日時点で、PyPIの最新は1.9.0です。告知はEOLの日付と移行先を示しているだけで、それまでに1.9系の修正版を出すかどうかには触れていません。年末までに新しい脆弱性が公表される可能性もあるため、NVIDIAの製品セキュリティのページで通知を購読しておくと見落としを防げます。

Text-to-SQLを使っていない環境もCVE-2026-65151の確認が要りますか？

勧告の影響版は1.4から1.6で、コンポーネントの限定はありません。Text-to-SQLを使っていなくても、この範囲の版なら影響版として扱います。ただし1.9.0へ上げれば65145と65151の両方が塞がるので、確認の手間を分ける必要はありません。nvidia-nat-vannaが入っていたかどうかは、優先順位を決める材料として見ます。

NeMo GuardrailsやNeMo Frameworkも今回の対象ですか？

勧告5912の対象はNeMo Agent Toolkitだけです。NeMo Guardrails、NeMo Framework、NeMo Speechなどの別の製品は入っていません。ただし、ツールキットの追加機能としてGuardrailsを組み込んでいる環境では、ツールキット側の版が1.9.0未満なら影響を受けます。製品名ではなく、入っているパッケージの名前で判断してください。

KEVに載っていない段階で、どこまで急ぐべきですか？

外から届く状態のサーバーがあるなら、今日のうちに入口を閉じます。CVSS 10.0で認証が要らず、修正版の公開から7週間がたっているため、差分から攻撃の手順を組み立てる時間は十分にありました。社内にしか届かない環境なら、次の定期更新を待たず今週中に1.9.0へ上げます。

関連記事

• MCP TypeScript SDKの脆弱性：2026年10月の7件の対象版と更新後に要る設定変更：MCPサーバーを作る側の部品で出た脆弱性を、版の照合と設定の変更から扱っています。
• LiteLLM 脆弱性：1.107.0侵害の影響確認と鍵の入れ替え・KEV掲載3件の修正版：LLMのAPIキーの入れ替えまで踏み込んだ、AI基盤の脆弱性対応の例です。
• Claude Agent SDKの脆弱性CVE-2026-96620とは？0.2.121への更新とresume検証のコード：別のエージェント開発キットで出た脆弱性の、更新と検証のコードです。
• NeMo Guardrailsとは？使い方と設定例、0.24の変更点とIORailsの注意点：ツールキットに組み込まれることの多いNVIDIAのガードレールの設定です。
• garakとは？NVIDIAのLLM脆弱性スキャナーの使い方と結果の読み方【v0.17.1】：移行後のエージェントをLLMの側から検査するときの道具です。