NVIDIA Display Driver CVE-2026-47522

Requires local access to a host running a vulnerable NVIDIA GPU Display Driver on Windows or Linux, AND the attacker must already hold high privileges (PR:H) to reach and invoke the affected kernel-mode driver interface. No user interaction is needed (UI:N). Affected products span GeForce, RTX/Quadro/NVS, and Tesla lines; per EUVD, GeForce driver builds prior to fixes such as 595.91.07/610.57.04/615.71.09/616.56, RTX/Quadro/NVS prior to 580.178.04/610.88/616.92, and Tesla prior to 596.86/615.71.09/616.92 (branch-dependent), with one GeForce 582.78 case limited to Maxwell, Volta, and Pascal architectures. Limiting factors: the PR:H requirement means this cannot be used for initial access - the attacker needs existing elevated privileges - which is the single biggest constraint on real-world risk.

This is a genuine but moderate-priority vulnerability. The CVSS 3.1 vector (AV:L/AC:L/PR:H/UI:N/S:U) is the dominant signal: exploitation is LOCAL and requires HIGH privileges (PR:H), meaning the attacker must already hold administrator/kernel-adjacent access on the host. This substantially lowers real-world risk despite the C:H/I:H/A:H full-impact triad, which is why the vendor score lands at 6.7 (Medium) rather than in the High/Critical range. No EPSS score, no CISA KEV listing, and no public POC were provided in the input, so there is no signal of active or imminent widespread exploitation. The 'RCE' tag overstates reach - with AV:L this is local code execution, not network-remote code execution. The SSVC read is: exploitation=none observed, automatable=no (local + high privilege), technical impact=total. Net: a real defect worth patching on the standard cadence, but not a drop-everything emergency; the PR:H prerequisite makes it primarily a privilege-escalation/sandbox-integrity concern for an attacker who already has elevated access rather than an initial-access vector.

An attacker who has already obtained high-privilege access on a Windows or Linux host with a vulnerable NVIDIA driver invokes an affected kernel-mode driver interface with crafted, improperly-validated input. Because input validation is inadequate in the kernel layer, the malformed request corrupts kernel state, enabling code execution in kernel context, escalation of privileges, information disclosure, data tampering, or a driver/system crash (DoS). No public exploit code was identified at time of analysis.