NVIDIA fixes 114 flaws in its GPU driver and vGPU: which version secures which branch

On 30 September 2026 NVIDIA published its security bulletin "GPU Display Driver – September 2026". It lists 114 CVEs, CVE-2026-47489 to CVE-2026-47604, for the Linux and Windows display drivers and for the vGPU software. Going by the table in NVIDIA's GitHub copy, 78 are rated High and 36 Medium, with a top base score of 7.8. heise reported on it on 1 October. Linux servers with NVIDIA cards need 615.71.09, 610.57.04, 595.91.07 or 580.178.04, depending on the driver branch.

What the bulletin says

Almost all entries describe bugs in the kernel-mode part of the driver, many of them in the open-source kernel module: use-after-free, memory permissions lost during DMA mapping, writes to read-only memory. The usual impacts NVIDIA lists are code execution, privilege escalation, denial of service, information disclosure and data tampering. 112 of the 114 CVEs have a local attack vector, two require physical access. 91 need low privileges, 21 high privileges and two none at all (our own count from the vector column of the bulletin).

heise notes that the advisory gives no indication of active exploitation. In the CVE record for CVE-2026-47574, CISA's assessment reads "Exploitation: none". The local-access requirement is little comfort on a GPU server: every container, every Jupyter kernel and every account with access to /dev/nvidia* counts as a local user for these vectors.

Critical or High

heise writes that the table on NVIDIA's support page rates CVE-2026-47574 as critical, while the CVE record says High. The flaw sits in the Virtual GPU Manager for Linux and, per its description, allows incorrect transfer of resources between security spheres. The GitHub copy of the bulletin and the CVE record at MITRE both give 7.8 and High. The support page answered our requests on 3 October with HTTP 403, so the critical label rests on heise alone. For planning this changes little: anyone running vGPU should treat CVE-2026-47574 as if it were critical.

heise also counts 16 flaws in the vGPU software. That matches the table if you count only the CVEs that affect the vGPU manager or guest drivers and nothing else. In total, 54 CVEs carry a row for the Virtual GPU Manager.

Fixed versions per branch

On Linux, 80 of the 114 CVEs affect the driver branches. For each branch, the bulletin lists every version before the fixed release as affected:

The values apply to GeForce, RTX/Quadro and Tesla alike, with the Windows exceptions noted in brackets. According to the notes in the bulletin, the Windows drivers 610.60, 596.71 and 582.67 shipped through hardware vendors also contain the fixes. Anyone on an older branch without its own row should move to the latest branch, says NVIDIA.

vGPU: host and guest go together

For vGPU the fixed releases are 20.2 and 19.6; everything up to and including 20.1 and 19.5 is affected. The Virtual GPU Manager comes as 595.91.04 (vGPU 20.2) or 580.178.05 (vGPU 19.6) on XenServer, VMware vSphere, RHEL KVM and Ubuntu, and as 596.84 or 582.78 on Azure Local and Windows Server. The guest drivers inside the VMs have to follow: 595.91.07 or 580.178.04 on Linux, 596.86 or 582.78 on Windows. An updated host with old guest drivers closes only part of the holes. Proxmox VE is not named in the list of hypervisors.

Containers do not ship the kernel module

On inference hosts, vLLM, llama.cpp or Triton usually run in containers, and their images bring the CUDA runtime and libraries. The kernel module nvidia.ko is loaded by the host, and all containers share that kernel. The NVIDIA Container Toolkit therefore requires a driver installed on the host. A freshly pulled image does nothing about the flaws fixed here. After the driver update, check in turn that the images still match the driver version. Which CUDA version current inference engines expect is covered in our post on vLLM 0.30 and llama.cpp 0.5.

The new driver is only active once the old module has been unloaded. As long as a process holds the GPU that cannot happen, and on a host with a running model server it means in practice: stop or redirect the services, reboot, bring them back up. With DKMS, the package update rebuilds the module for the running kernel. A self-built or patched module has to be rebuilt from the fixed source, and a plain version comparison tells you little in that case. Also on 3 October, seven stable kernels were released; a kernel update and the driver change fit into the same maintenance window.

nvidia-smi --query-gpu=driver_version --format=csv,noheader returns the driver version. The first three digits give the branch, and the table tells you whether the host is affected. How easily a patch round gets stuck on a single host is described in Patch round: one host stops the whole fleet. GPU hosts are better served by their own planned window than by the nightly batch run.

Where we stand

Our three GPU inference hosts, with five RTX 5090 and one RTX 4060 Ti between them, all report version 610.57.04 in nvidia-smi on 3 October 2026, the first fixed release on the R610 branch. One of the hosts runs a self-built open kernel module carrying that version number. Whether it contains the fixes is decided by the source the build is based on.

Our recommendation: read the driver version on every GPU host, compare it with the table and plan a window with a reboot for anything below the fixed release. vGPU environments move manager and guest drivers to 20.2 or 19.6 together.

Further sources

• NVIDIA Security Bulletin 5861, GitHub copy in Markdown: all 114 CVEs, ratings, affected and fixed versions
• NVIDIA support page for bulletin 5861: original page, blocked for automated requests on 3 Oct 2026 (HTTP 403)
• CVE-2026-47574 at cve.org: record for the vGPU flaw, rated High
• CVE-2026-47574 as JSON at MITRE: CVSS 7.8 and CISA assessment "Exploitation: none"
• heise: Treiber-Lücken gefährden Linux- und Windows-PCs mit Nvidia-GPU: German report of 1 Oct 2026 with the version list and the rating conflict
• NVIDIA Container Toolkit, installation guide: host driver as a prerequisite
• LWN: Seven stable kernels for Saturday: kernel releases of 3 Oct 2026