NVIDIA vGPU Manager CVE-2026-47502

Requires the host to be running the NVIDIA vGPU Virtual GPU Manager (GPU virtualization/vGPU deployment on Windows or Linux hosts, across GeForce, RTX/Quadro/NVS, and Tesla driver branches) and the attacker to hold at least low-privilege authenticated user access inside a guest VM (PR:L). Exploitation is local (AV:L) with low complexity (AC:L) and no user interaction, so it cannot be performed remotely or against a host without an existing guest foothold; systems not using NVIDIA vGPU virtualization are not exposed to this attack surface.

The provided CVSS 3.1 vector (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, base 7.8 HIGH) indicates a locally-exploitable, low-complexity flaw requiring only low guest-level privileges and no user interaction, yielding full confidentiality, integrity, and availability impact via memory corruption - consistent with the CWE-190 integer-overflow-to-memory-corruption description in the kernel-mode layer of the vGPU Virtual GPU Manager. No EPSS score, SSVC decision data, KEV listing, or POC were supplied, so there is no public exploit identified at time of analysis and no evidence of active exploitation. Real-world priority is tempered by the local attack vector and the requirement for an authenticated foothold as a guest user inside a VM running on NVIDIA vGPU, but is elevated by the trust-boundary nature of the bug (a guest user attacking the host-side hypervisor GPU manager) and low attack complexity. One nuance worth verifying: scope is rated S:U despite the guest-to-host-component crossing that vGPU flaws typically imply, so the practical blast radius (does memory corruption in the VGPU Manager affect only the guest context or the host/other tenants?) should be confirmed against NVIDIA's advisory. Overall this is a genuine patch-worthy issue for GPU-virtualization operators rather than a mass-exploitation internet-facing threat.

An attacker with ordinary user access inside a guest VM on a host running the NVIDIA vGPU Virtual GPU Manager issues crafted requests to the kernel-mode vGPU interface, triggering an integer overflow that leads to controlled memory corruption. By grooming the overflow, the attacker escalates privileges or executes code in the kernel-mode component, potentially crashing the service (DoS) or tampering with data belonging to the virtualization layer. No public proof-of-concept was provided, and exploitation requires an existing authenticated guest foothold and local access.