NVIDIA GPU Driver EUVD-2026-90136

Requires an attacker to already have unprivileged local access and the ability to issue GPU driver commands (e.g., open the NVIDIA kernel driver device and submit ioctls) on a system running an affected NVIDIA GPU Display Driver for Windows or Linux - no authentication elevation, no user interaction, and no special non-default feature toggle is named in the description; the UAF is reached simply by issuing a particular sequence of driver commands. Limiting factors: local access is mandatory (not remotely exploitable), the specific command sequence to win the use-after-free must be constructed, and impact is highest in shared/virtualized GPU environments ('Guest Driver'/'Virtual Gpu Manager', Tesla/vGPU) where it breaks tenant isolation.

Moderate, patch-worthy local privilege-escalation risk rather than an internet-facing emergency. The CVSS 3.1 vector (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, 7.8 HIGH) is internally consistent and I agree with it: exploitation requires local access and existing low privileges, but attack complexity is low and no user interaction is needed, and impact is full CIA (code execution in the kernel driver). No EPSS score, no CISA KEV listing, and no public POC are present in the provided data, so there is no evidence of active exploitation - this is a vendor-reported (NVIDIA) issue with a patch already available via bulletin 5861. The 'RCE' tag overstates reachability: AV:L makes this a local UAF, not remote code execution, so treat network-exploitation framing as inaccurate. Priority is elevated on multi-tenant and virtualized GPU hosts (the CPE set and 'Guest Driver'/'Virtual Gpu Manager' tags indicate vGPU/VDI/cloud-GPU deployments) where an unprivileged local user escaping to kernel is a meaningful tenant-isolation breach; on single-user workstations it is a standard local-privesc bug to patch in routine cycles.

An unprivileged local user (or low-privileged process/tenant on a shared GPU host) issues a specific sequence of GPU driver commands that frees a kernel object still referenced by the driver, then reallocates and controls that freed memory to hijack execution in kernel context. No public exploit code is identified at time of analysis, and because the attack vector is local (AV:L) the attacker must already have code-execution foothold on the machine; success yields kernel-level code execution and privilege escalation.