NVIDIA Display Driver CVE-2026-47585

Requires local, authenticated access to a Windows host running the affected NVIDIA GPU Display Driver (GeForce, RTX/Quadro/NVS, or Tesla) - the attacker must already be able to execute code as a low-privileged user (PR:L) to reach the vulnerable kernel module and supply the input that triggers the integer underflow. No user interaction and no special driver configuration is stated as required; the attack is not network-reachable (AV:L limits it to local access). Realistic risk is concentrated on shared, multi-user, VDI, and cloud-GPU deployments where an unprivileged tenant is present on the same host; single-user desktops where the attacker would already need a foothold face lower marginal risk.

The provided 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 with the description: this is a LOCAL, low-complexity, low-privilege kernel-mode flaw, NOT a remote one. The 'RCE' tag is therefore misleading - exploitation requires the attacker to already have local, authenticated code-execution on the host (PR:L), so this is a privilege-escalation / local-code-execution primitive rather than a network-reachable RCE. No EPSS score, no CISA KEV listing, and no public POC are present in the input, so there is no signal of active or imminent exploitation; this reads as a real-but-not-urgent local kernel bug patched proactively (NVIDIA-reported via product-security bulletin 5861). SSVC-style read: exploitation=none observed, automatable=no (local access prerequisite), technical impact=total (full C/I/A on the affected component). Priority is moderate: high technical impact but gated behind local access, which matters most on multi-user, VDI, or cloud-GPU hosts where an unprivileged tenant could escalate to kernel. The 'Microsoft' vendor tag is incorrect - the affected product is an NVIDIA driver that merely runs on Windows.

A local, low-privileged user (or malware already running in a standard user context) on a Windows machine with an NVIDIA GPU driver issues crafted input to the vulnerable kernel module, triggering an integer underflow that corrupts kernel memory. By grooming the resulting out-of-bounds condition, the attacker escalates to SYSTEM/kernel privileges or crashes the driver for denial of service. No public exploit code is identified at time of analysis, and network access is not sufficient - local access is required.