NVIDIA issues May 2026 security bulletins for GPU drivers and TensorRT‑LLM

NVIDIA published coordinated security bulletins in mid‑May 2026 covering both its GPU display drivers and the TensorRT‑LLM inference stack, and it is urging administrators to apply available updates immediately.

The GPU display‑driver bulletin, updated May 18, lists more than a dozen CVEs affecting Windows and Linux branches and assigns several high CVSS v3.1 scores, including CVE‑2026‑24187 (use‑after‑free) with an 8.8 rating.

NVIDIA tabulated which Windows and Linux driver branches and builds include the fixes and directs users to download updated packages from its Driver Downloads page or, for vGPU/cloud gaming, from the NVIDIA Licensing Portal. Administrators should match their branch (R595, R580, R535, etc.) to the updated driver listed by NVIDIA.

The display bulletin also covers vGPU software and lists two vGPU CVEs (CVE‑2026‑24200 and CVE‑2026‑24201) tied to virtual GPU manager flaws that may allow use‑after‑free and out‑of‑bounds access. Organizations running virtualized GPU environments should include vGPU updates in their remediation plans.

Separately, NVIDIA issued a TensorRT‑LLM security bulletin (initial release May 19) that identifies deserialization and race‑condition vulnerabilities in its LLM runtime and RPC/MPI subsystems. The vendor says affected TensorRT‑LLM releases prior to v1.2 are impacted and that the fixes are available in v1.2 and v1.2.1.

Two TensorRT‑LLM CVEs called out in the bulletin — CVE‑2025‑33255 and CVE‑2026‑24163 — describe unsafe deserialization in the MPI server and RPC testing code, which NVIDIA warns could be exploited to achieve code execution, data tampering, or information disclosure. That technical impact makes these issues especially relevant to inference endpoints.

Because the TensorRT‑LLM flaws lie in the inference and inter‑process communication path, data‑center operators and platform teams running LLM acceleration stacks should treat the TensorRT‑LLM update as a priority to reduce the chance of an attacker using inference requests as an attack vector. The vendor explicitly recommends upgrading to TensorRT‑LLM v1.2.1 where listed.

NVIDIA also offers a tactical mitigation for multi‑GPU deployments: use the trtllm‑llmapi‑launch executable rather than instantiating the RPCServer class directly to reduce exposure to CVE‑2025‑33255 while you deploy updates. Teams that cannot patch immediately should evaluate this and other compensating controls.

Operationally, platform engineers should sequence patches carefully — prioritize TensorRT‑LLM on inference nodes exposed to tenant traffic, then roll driver updates during maintenance windows after testing for compatibility with CUDA and runtime stacks. Maintain backups, test rollback paths, and validate model outputs after upgrades. (Best‑practice guidance based on standard change‑management principles.)

NVIDIA’s GitHub repository shows a v1.2.1 TensorRT‑LLM release (tag v1.2.1) and release notes that indicate fixes and infrastructure updates; operators who deploy from source or container images should pull the v1.2.1 tag or the vendor‑supplied container images and follow the project’s upgrade instructions.

The display‑driver bulletin includes detailed tables mapping CVE IDs to affected branches and the updated driver builds that contain the fixes, so system owners should consult that vendor table when deciding which binary to install. NVIDIA reminds customers that hardware vendor driver packages may also contain the fixes and that the table could be updated as new information becomes available.

NVIDIA closes the TensorRT‑LLM bulletin with acknowledgements to external reporters and a reminder to subscribe to NVIDIA Product Security notifications for future advisories. For teams tracking exposure, the vendor’s PSIRT recommendations and the two May bulletins are the authoritative starting points for remediation.