NVIDIA Display Driver CVE-2026-47543

Requires local access with HIGH privileges (PR:H) - the attacker must already be an administrator/root-equivalent user on a host running the NVIDIA GPU Display Driver for Windows or Linux (GeForce, RTX/Quadro/NVS, or Tesla). No user interaction is needed (UI:N) and no special product feature toggle is named; the trigger is submitting improperly validated input to the kernel-mode driver layer. The dominant limiting factor is the PR:H prerequisite: an unprivileged local user or a remote attacker cannot reach this directly, so real-world risk is confined to scenarios where a high-privilege account or process is compromised and used to attack the kernel (e.g., sandbox/kernel-integrity bypass in hardened or multi-tenant GPU hosts).

The CVSS 3.1 vector (AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H, base 6.7) is internally consistent and describes a LOCAL, HIGH-privilege vulnerability, not a remote one - despite the 'RCE' tag, network exploitation is not possible (AV:L). The most important limiting signal is PR:H: an attacker must already hold high/administrative privileges on the host before triggering the flaw, which sharply reduces net escalation value and places this below the many PR:L siblings in NVIDIA bulletin 5861. No EPSS score, no CISA KEV listing, and no public POC were provided, so exploitation status is 'no public exploit identified at time of analysis'. There are no conflicting signals in the vector itself; the main conflict is between the marketing-style 'RCE' tag and the actual local-only vector - verify that this is local kernel-mode driver abuse, not remote code execution. Overall this is a moderate-severity, defense-in-depth kernel driver bug rather than a top-priority emergency: real for hardened multi-tenant/workstation environments but gated by the PR:H precondition.

An attacker who already has high/administrative privileges on a Windows or Linux system with NVIDIA GPU drivers installed submits malformed input to the kernel-mode driver layer, which fails to validate it properly. The resulting memory/state corruption is leveraged for kernel-level code execution, privilege escalation into the kernel context, or a driver/system crash. No public exploit code is known, and exploitation requires prior high-privilege local access.