CUDA Toolkitの脆弱性（CVE-2025-33228〜33231・CVE-2026-65160）｜Nsight・nvJPEGの影響版と13.4.2以降への更新手順

CUDA Toolkitには、2026年に入ってNVIDIAのセキュリティ告知が2本出ています。1月20日の告知5755は、同梱の性能解析ツールNsight SystemsとNsight Visual Studio Editionの4件（CVE-2025-33228〜33231）で、CUDA Toolkit 13.1で修正されました。11月3日の告知5910は、JPEGをGPUで復号するライブラリnvJPEGの1件（CVE-2026-65160）で、修正版は13.4 Update 1、アーカイブの版番号では13.4.2です。5件の中身と影響を受ける版、Pythonのライブラリが別に抱える古いnvJPEGの見つけ方、更新の手順を、NVIDIAの告知とNVDの登録情報に基づいて整理します（2026年11月11日時点）。

まとめ：Toolkitは13.4.2以降で5件とも修正済み、ライブラリ同梱のnvJPEGは別に確認

Nsightの4件は13.1より前のすべての版、nvJPEGの1件は13.4.1以前のすべての版が対象です。5件をまとめて解消できるのは13.4.2以降で、2026年11月11日時点の最新は13.5.0（2026年11月公開）です。13.1〜13.4.1を使っている環境は、Nsightの4件は解消済みでも、nvJPEGの1件が残っています。

5件とも攻撃元区分はローカル（AV:L）で、細工したファイルや文字列を利用者に扱わせることが前提です。ネットワーク越しに直接突ける脆弱性ではありませんが、外から届いたファイルや画像を処理する経路があれば悪用されえます。急ぐべきなのは、複数の人が同じGPUサーバーにログインして使う共用環境と、外から受け取ったプロファイル結果や画像を処理する環境です。もう1つ見落としやすいのが、PyTorchのtorchvisionのようにnvJPEGを自前のwheelに同梱しているライブラリです。Toolkitを13.5.0へ上げても、その中のnvJPEGは置き換わりません。

CUDA Toolkitの告知2本と影響を受ける版の早見表

NVIDIAは製品ごとのセキュリティ告知をGitHubのCVE索引（2026年分）にまとめています。影響製品が「CUDA Toolkit」の告知は、2026年11月11日時点で次の2本です。

告知5755（2026年1月）と告知5910（2026年11月）の5件の一覧表

VSEはVisual Studio Editionの略です。弱点の分類は、33228と33230がCWE-78（OSコマンドインジェクション）、33229と33231がCWE-427（制御されない検索パス）、65160がCWE-369（ゼロ除算）です。告知5755は4件の影響版を「All versions prior to CUDA Toolkit 13.1」とし、13.1そのものは修正済みです。告知5910はCUDA Toolkitの影響版を「0 to 13.4.1」、修正版を「13.4 U1」としています。NVDへの登録は、4件が2026年1月20日、65160が2026年11月3日です。CISAの悪用確認済み脆弱性の一覧（KEV）は2026年11月9日版で、5件とも載っていません。

13.4.1と13.4.2の境界とリリースノートの「13.4 Update 1」の対応

告知5910の修正版「13.4 Update 1」は、CUDA Toolkitのアーカイブの版番号とずれています。アーカイブには13.4.0 Developer Preview（2026年7月）、13.4.1（9月）、13.4.2（9月）、13.4.3（10月）、13.5.0（11月）の順で並びます。版ごとのリリースノートを開くと、13.4.1は「CUDA 13.4」、13.4.2は「CUDA 13.4 Update 1」、13.4.3は「CUDA 13.4 Update 2」の部品表を載せています。

13.4.2のリリースノートには、nvJPEGの修正として「Fixed parsing issues that could cause crashes or hangs when decoding malformed JPEG bitstreams」とあります。告知の公表は11月3日ですが、修正を含む版は9月に出ていたことになります。nvcc --version の「release 13.4」だけでは13.4.1と13.4.2を区別できないので、末尾の「V13.4.59」と「V13.4.92」で見分けます。

公開日が新しくても対象に入る13.0.3などの保守版

判断の基準は公開日ではなく版番号です。アーカイブには、告知5755より後の2026年4月に公開された13.0.3や、5月公開の12.9.2が並んでいます。どちらも版番号は13.1より前なので、告知5755の表に照らすと4件の対象です。告知の注記は「古いブランチのリリースも影響を受ける。古いブランチを使っている場合は最新のブランチへ上げること」としており、12系や13.0系の中での修正版は示されていません。13.3.1（6月）や13.2.2（7月）も、4件は解消済みですが65160の対象です。

修正版13.1で変わった点：CUDA TileとWindowsのドライバ非同梱

13.1（2025年12月）は脆弱性の修正版であると同時に、機能の追加が大きい版です。NVIDIAのCUDA 13.1の紹介記事は、タイル単位でカーネルを書くCUDA Tileを中心に挙げています。仮想命令セットのCUDA Tile IRと、Pythonで書くcuTile Pythonの2つで、最初の版の対応GPUはAmpere・Ada・Blackwell（compute capability 8.x・10.x・11.x・12.x）です。

更新の手順に響くのは、ドライバの扱いです。リリースノートは「The NVIDIA driver is no longer bundled with the CUDA Toolkit – on Windows starting with CUDA 13.1, and on Linux starting with CUDA 13.4」としています。12系から13.1以降へ上げると、WindowsではToolkitのインストーラがドライバを入れなくなります。既存のCUDA 13系のアプリは580以上のドライバで動きますが（マイナーバージョン互換）、13.5の新機能にはR620以降のドライバが要ります。CUDAの版とドライバの関係の全体はCUDAの仕組みとCUDA 12と13の違いにまとめています。

Nsight SystemsとNsight VSEで任意コード実行に至る仕組み

告知5755の4件は、それぞれ別の箇所の欠陥です。共通するのは、ツールが外から渡された文字列や読み込み先を信用しすぎた点です。

gfx_hotspotレシピと.runインストーラのOSコマンド注入

CVE-2025-33228は、Nsight Systemsの解析レシピ「gfx_hotspot」の処理で起きます。NVDの説明は、process_nsys_rep_cli.py スクリプトでOSコマンドが注入されるというものです。細工した文字列を渡されたこのスクリプトを、利用者が手動で実行することが条件になります。

CVE-2025-33230は、Linux向けの .run 形式のインストーラで、インストール先のパスに細工した文字列を指定されるとコマンドが注入されます。自分で正しいパスを指定して入れる限り問題は起きません。危険なのは、他人が用意したインストール手順やスクリプトをそのまま実行する場合です。

Windows版のDLL検索パスとNsight Monitorの権限での実行

CVE-2025-33231は、Windows版のNsight SystemsがDLLを読み込むとき、安全でない検索パスを使っていた問題です。攻撃者が書き込める場所に同名の不正なDLLを置くと、Nsight Systemsの起動時に読み込まれます。攻撃条件の複雑さは高（AC:H）と評価され、4件で唯一6.7（Medium）です。

CVE-2025-33229は、Nsight Visual Studio EditionのNsight Monitorの欠陥で、攻撃者がMonitorと同じ権限で任意のコードを実行できます。Monitorが高い権限で動いている環境では、権限の昇格につながります。Nsight Visual Studio Editionは、WindowsのCUDA Toolkitインストーラのサブパッケージ nsight_vse_13.5（13.5の場合）として入ります。Windows向けのインストールガイドによると、サブパッケージはいずれもコントロールパネルの「プログラムと機能」から個別に削除できます。サイレントインストールの -s にサブパッケージ名を並べれば、最初から入れない構成にもできます。

nvJPEGのゼロ除算（CVE-2026-65160）とPythonの環境に残る古いnvJPEG

告知5910の1件は、Nsightの4件とは性質が違います。開発ツールではなく、アプリケーションが実行時に呼び出すライブラリの欠陥です。

細工したJPEGの復号でサービス停止に至る条件

告知の説明は「攻撃者がゼロ除算を起こせる。悪用されるとサービス拒否につながる」というもので、ベクトルは AV:L/PR:N/UI:R、機密性と完全性への影響はなし、可用性への影響が高（A:H）です。コードの実行や情報の漏えいではなく、復号の処理を落とす種類の欠陥です。問題になるのは、外から受け取った画像をnvJPEGで復号する処理です。画像のアップロードを受け付けてGPUで縮小するAPIや、外部の画像データセットを読む学習ジョブがこれに当たり、細工したJPEGの復号によって、処理プロセスやジョブが停止する可能性があります。サービス全体への影響は、プロセスの分離や再起動の構成にも依存します。

torchvision同梱nvJPEGとToolkit更新の適用範囲

PyTorchの画像ライブラリtorchvisionは、decode_jpeg のドキュメントに「If a cuda device is specified, the image will be decoded with nvjpeg」とあるとおり、GPUでの復号にnvJPEGを使います。2026年11月11日にPyTorch公式の配布サイトからLinux x86_64向けのwheelを取得し、GPUの無いLinuxコンテナで中身を調べた結果が次の表です。「nvJPEGの版」はライブラリ自身が返す版（nvjpegGetProperty）、「ビルドのCUDA」はライブラリ内に残るコンパイラの版です。

torchvisionのwheelは、nvJPEGを名前にハッシュの付いた別ファイルとして同梱しています。画像処理の本体 image_stable.so は、このファイルを同じwheelの中から読む設定（RPATH が $ORIGIN/../torchvision.libs）になっていました。13.4 Update 1に同梱されるnvJPEGは13.2.3.58なので、torchvisionが同梱する13.0.1と13.1.0は修正前の版です。サーバーのCUDA Toolkitを13.5.0へ上げても、このファイルは置き換わりません。同梱のnvJPEGへの対策は、修正版のnvJPEGを含むtorchvisionの配布物へ更新することです。ビルド時のCUDA版だけで判断せず、実際に同梱・読み込みされるnvJPEGの版を確認します。修正版を含む配布物が出るまでは、信頼できない画像をGPUで復号しない（device="cpu" で復号してから転送する）運用で避けます。

手元の環境のnvJPEGは、次のように調べます。nvjpegGetPropertyはGPUが無くても呼べます。13.2.3以降なら13.4 Update 1と同じかそれより新しい版です。

# pip で入れた nvJPEG の版（13.2.3.58 以降が 13.4 Update 1 と同じ版）
pip show nvidia-nvjpeg 2>/dev/null | grep -i '^version'

# torchvision が同梱する nvJPEG のライブラリの版（13.2.3 以降なら修正版と同じかそれ以降）
python - <<'PY'
import ctypes, importlib.util, pathlib
spec = importlib.util.find_spec("torchvision")
if spec is None or spec.origin is None:
    raise SystemExit("torchvision が未導入、または導入先を特定できません")
d = pathlib.Path(spec.origin).parent.parent / "torchvision.libs"
for lib in sorted(d.glob("libnvjpeg*")):
    l = ctypes.CDLL(str(lib))
    v = [ctypes.c_int() for _ in range(3)]
    for i in range(3):
        rc = l.nvjpegGetProperty(i, ctypes.byref(v[i]))  # 0=MAJOR 1=MINOR 2=PATCH
        if rc != 0:
            raise RuntimeError(f"{lib.name}: nvjpegGetProperty failed: {rc}")
    print(lib.name, ".".join(str(x.value) for x in v))
PY

この例はLinux版のwheelを前提にしています。nvJPEGを同梱していないtorchvisionでは何も表示されません。画像の読み込みにnvJPEGを使う別のライブラリNVIDIA DALIにも、2026年10月に告知5900（CVE-2026-65147〜65150、2.3で修正）が出ています。DALIを使っている場合は、DALIの版も別に確かめます。

ローカル前提の脆弱性が危険になるGPU環境と更新の優先順位

5件ともローカルの攻撃で、利用者の操作が前提です。CVSSの点数より、細工した入力が入り込む経路があるかで緊急度が決まります。

共用GPUサーバー・CI・外部ファイル解析の更新優先度

複数の利用者が同じLinuxのGPUサーバーにSSHで入って使う構成は、最優先で更新してください。低い権限の利用者が、他人が実行するスクリプトや解析対象に細工を仕込める状態だからです。研究室の共用サーバーや、社内で使い回しているGPUのVMが典型です。外部から受け取ったプロファイル結果を解析する環境と、利用者がアップロードした画像をGPUで復号するサービスも、細工された入力を扱う経路があるため優先度が上がります。

CIのコンテナイメージに古いCUDAのベースイメージが残っていると、ホストを更新しても解析ジョブが使うのは古いNsightやnvJPEGのままです。イメージの中身を点検してパイプラインで止める考え方はDockerの脆弱性診断をCI/CDに組み込む手順が参考になります。逆に、1人だけが使う開発用PCで自分のコードと自分の画像だけを扱っているなら、攻撃の前提が成り立ちにくく、次の定例更新で十分です。GPUを借りて使う場合の環境の選び方はRunpodのGPUクラウドの選び方、学習環境の組み方はファインチューニングに必要なGPUと学習コードで扱っています。

共用GPUサーバーで他人が書き込める場所を減らす権限点検

CVE-2025-33231のDLL検索パスのように、他人が書き込める場所に細工したファイルを置かれて成立する欠陥は、次の点検で攻撃の足場を減らせます。共用のLinuxサーバーでは、更新とあわせて確かめておきます。

# PATH に含まれるディレクトリのうち、グループかその他のユーザーが書き込めるものを探す（Linux）
echo "$PATH" | tr ':' '\n' | xargs -I{} find -L {} -maxdepth 0 \( -perm -g+w -o -perm -o+w \)
# CUDA の導入先（リンク先を含む）に、グループかその他のユーザーが書き込めるものが無いかを探す
find -L /usr/local/cuda-* \( -perm -g+w -o -perm -o+w \) -print

表示された場所は権限を見直します。この例が見るのは通常の権限ビットだけなので、ACLを使っている環境では getfacl でも確かめ、エラーが出た場所は調べられていないものとして扱います。共有の作業ディレクトリは利用者ごとに分けます。Windowsの開発用PCでは、ダウンロードフォルダなど利用者が自由に書き込める場所からNsightを起動しない運用にするだけでも、DLLの置き換えの余地が減ります。

CUDA Toolkitの版を確かめて13.4.2以降へ更新する手順

CUDA Toolkitは同じマシンに複数の版が並んで入っていることが多く、PATHが指している版と、ジョブが既定で呼び出す版がずれることがあります。版の確認から始めます。

nvcc・nsysの版の確認と複数版が残っていないかの点検

# CUDA Toolkit の版（末尾の V13.4.59 などまで見る）
nvcc --version
# Nsight Systems の版（CUDA Toolkit 同梱版と単体インストール版が別に入っていることがある）
nsys --version
# Linux：導入済みの Toolkit の場所を一覧（複数版が残っていないか）
ls -d /usr/local/cuda-*

Windowsでは、次のコマンドをPowerShellで実行します。

# Nsight Systems の実体の場所
Get-Command nsys | Select-Object Source

Nsight Systemsは単体でもインストールできるため、nsys --version の結果がCUDA Toolkit同梱の版と違うことがあります。13.4.2に同梱されるNsight Systemsは2026.3.2.476、13.5.0では2026.5.2.323です。/usr/local/cuda-12.4 のように古い版のディレクトリが残っていると、そこに含まれる古いNsightやnvJPEGを誰かが使う可能性があります。使わない版は削除してください。nvidia-smi の表示にあるCUDA Versionはドライバ側の値で、Toolkitの版ではありません（nvidia-smiの見方で解説しています）。

導入済みの全版を13.1と13.4.2の基準で振り分けるシェルの例

共用サーバーで複数の版が残っている場合は、導入先を順に調べて一覧にするほうが確実です。次の例は、/usr/local/cuda-* にある各版の nvcc の版（V13.4.92 など）を取り出し、Nsightの4件とnvJPEGの1件それぞれの対象かどうかを表示します。

#!/usr/bin/env bash
# /usr/local/cuda-* の各版を、告知5755（13.1未満）と告知5910（13.4 Update 1 未満）の基準で振り分ける
lt() { [ "$1" != "$2" ] && [ "$(printf '%s\n%s\n' "$1" "$2" | sort -V | head -n1)" = "$1" ]; }
for d in /usr/local/cuda-*; do
  [ -x "$d/bin/nvcc" ] || continue
  v=$("$d/bin/nvcc" --version 2>/dev/null | sed -n 's/.*, V\([0-9.]*\).*/\1/p')
  if [ -z "$v" ]; then echo "$d  判定不能（nvcc の版を取れない）"; continue; fi
  nsight="修正済み相当"; nvjpeg="修正済み相当"
  lt "$v" "13.1" && nsight="対象"
  lt "$v" "13.4.92" && nvjpeg="対象"
  echo "$d  V$v  Nsight4件:$nsight  nvJPEG:$nvjpeg"
done

この表示は、nvccの版から「その版のToolkitに標準で入る部品」を推定したものです。単体で入れたNsight Systemsや、Pythonのライブラリが同梱するnvJPEGはこの例では判定できないので、前の手順で別に確かめます。「対象」が1つでも出た版は、使っていなければ削除します。使っている場合はGPU・OS・依存ライブラリの対応を確認して13.4.2以降へ更新します。Maxwell・Pascal・Volta向けのコンパイルとライブラリ対応はCUDA 13.0で削除されているため、これらのGPUでは単純に置き換えず、影響部品の削除や処理経路の制限を検討します。13.4.3は13.4.2と同じ V13.4.92 を返すため、どちらも「修正済み相当」と表示されます。シンボリックリンクの /usr/local/cuda がどの版を指しているかも、readlink -f /usr/local/cuda で確かめておくと、既定で呼ばれる版を取り違えずに済みます。

13.5.0への更新とGPUドライバを別に管理する際の注意点

2026年11月11日時点のCUDA Toolkitのダウンロードページは13.5.0を配布しています。13.1の章で触れたとおりドライバはToolkitと別に入れるので、13.5の新機能を使うならドライバもR620の系列へ上げます。

学習済みモデルや社内のツールが特定のCUDAの版に依存している場合は、いきなり13.5系へ上げず、まず13.4系の13.4.2以降で依存関係が動くかを検証環境で確かめます。13.4.2と13.4.3は同じ部品の版（nvcc 13.4.92・nvJPEG 13.2.3.58）を載せているので、どちらを選んでも5件の対策としては同じです。CUDA Graphsのようにランタイムの機能を使い込んだコードは、版を上げたあとに挙動や性能を測り直します（CUDA Graphsの仕組みとCUDA 13の注意点）。

CUDA Toolkitと関連製品のセキュリティ告知の確認手順

新しい版にセキュリティの修正が含まれるかは、リリースノートではなく告知で確かめます。告知5910のように、修正を含む版（9月）より2か月近く遅れて告知が出ることもあります。NVIDIAの告知索引はCSVでも公開されているため、次のように絞り込めます。

# 2026 年の NVIDIA 告知索引から CUDA Toolkit・Nsight・nvJPEG の行だけを取り出す
curl -s https://raw.githubusercontent.com/NVIDIA/product-security/main/2026/CVE_index.csv \
  | grep -iE 'CUDA Toolkit|Nsight|NVJPEG'

2026年11月11日に実行すると、5件に加えてNsight Graphicsの行（CVE-2025-33206、告知5738）も表示されます。Nsight Graphicsはグラフィックスのデバッグ用の別ツールで、Toolkitには同梱されません。量子計算向けのCUDA-QのCVE-2026-24189（CVSS 8.2、0.14.0で修正）も、名前が似ていますが別の製品です。製品名の列で読み分けてください。

ドライバの告知も別に出ます。2026年9月30日の告知5861には、Windows向けGPUドライバのCUDAドライバ部分で外部のDLLを読み込める脆弱性（CVE-2026-47570、CVSS 7.8）が含まれています。Toolkitを13.5.0にしてもドライバの更新は別に要ります。告知はNVIDIA Product Securityで購読できます。2026年10月27日にはNeMo Agent Toolkitの脆弱性CVE-2026-65145も公表されており、NVIDIA製品の告知は製品ごとに出るため、使っている製品名で索引を引きます。

GPUサーバーを複数の部署やプロジェクトで共有していると、誰がどの版のToolkitやドライバ、Pythonのライブラリを入れたかが分からなくなりがちです。導入済みの版と権限設定をまとめて第三者の目で点検したい場合は、一創の脆弱性診断・セキュリティ診断で、サーバーやアプリケーションの診断と対策の優先順位付けを支援しています。LLMアプリ側の脆弱性の確かめ方はNVIDIAのLLM脆弱性スキャナーgarakが参考になります。

よくある質問

CUDA Toolkit 13.1を使っていれば、脆弱性の影響はありませんか？

Nsightの4件（CVE-2025-33228〜33231）は13.1で修正済みです。ただし、2026年11月3日に公表されたnvJPEGのCVE-2026-65160は13.4.1以前のすべての版が対象で、13.1も含まれます。5件をまとめて解消するには13.4.2（13.4 Update 1）以降へ上げます。

インターネットから直接攻撃される脆弱性ですか？

違います。5件とも攻撃元区分はローカルで、利用者がツールやスクリプトを実行したり、細工したファイルを開いたりすることが前提です。危険が大きいのは、複数人がログインする共用のGPUサーバーや、外部から受け取ったファイルや画像を処理する環境です。

Nsight Visual Studio Editionを使っていなければ削除してよいですか？

削除して構いません。WindowsのCUDA Toolkitではサブパッケージ（13.5なら nsight_vse_13.5）として入り、コントロールパネルの「プログラムと機能」から個別に削除できます。CVE-2025-33229はこのNsight Visual Studio EditionのNsight Monitorの欠陥なので、使わない環境では削除すれば攻撃の対象そのものが無くなります。

GPUドライバも一緒に更新する必要がありますか？

この5件はToolkit側の問題で、ドライバの更新は不要です。ただしCUDA 13系のアプリには580以上のドライバが要り、13.5の新機能はR620以降が前提なので、12系から上げる場合はドライバの版も確認します。別件として、2026年9月30日の告知5861でWindows向けGPUドライバのCVE-2026-47570が公表されているので、ドライバはドライバで修正版を確認してください。

すでに悪用されたかどうかを確かめる方法はありますか？

専用の痕跡は告知に示されていません。共用サーバーなら、Nsightのスクリプトやインストーラを誰がいつ実行したかをシェルの履歴や監査ログで確かめ、利用者が書き込める場所に置かれた不審なDLLやスクリプトがないかを点検します。nvJPEGの1件はサービス停止の欠陥なので、画像を処理するサービスが原因不明で落ちていないかをログで確かめます。CISAのKEV（2026年11月9日版）には5件とも載っておらず、NVIDIAの告知にも悪用についての記述はありません。ただし、どちらも悪用が無いことの保証ではありません。

関連記事

• CUDAとは？読み方と仕組み・CUDA 12と13の違い・始め方【13.4対応】
• nvidia-smiの使い方｜GPU使用率とメモリの見方・CSV記録・DCGMへの移行判断
• CUDA Graphsとは？仕組みと使い方、PyTorch・vLLMでの設定とCUDA 13の注意点
• NeMo Agent Toolkitの脆弱性CVE-2026-65145：1.9.0への更新と2026年末EOL前の移行判断
• Dockerの脆弱性診断をCI/CDに組み込む手順｜Trivy・Docker Scout・Grypeの終了コードと結果の直し方