NVIDIA vGPU Manager CVE-2026-47574

Requires the target host to be running the NVIDIA vGPU Virtual GPU Manager on Linux (a virtualization/vGPU deployment, not a standard desktop driver), and the attacker must already hold local low-privileged access (PR:L) to a context served by that manager - e.g. a guest VM or local account on the hypervisor host. Limiting factors: the attack vector is local (AV:L), not network, so no remote unauthenticated path exists; exploitation is gated on prior authenticated access and on the specific vGPU Manager component being installed and active. No user interaction is required (UI:N) and complexity is low (AC:L) once access is obtained.

This is a genuine local privilege-escalation class issue rather than a remotely-triggerable one, despite the 'RCE' tag. 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: an already-authenticated local low-privilege actor exploits improper resource transfer between spheres (CWE-669) in the Linux vGPU Virtual GPU Manager with low complexity and no user interaction, yielding full C/I/A impact on the host. No EPSS score, no CISA KEV listing, and no public POC were provided, so there is no evidence of active exploitation or automation - this is a patch-in-normal-cycle HIGH, not an emergency. CONFLICT/CAVEAT: the 'RCE' tag overstates reachability (AV:L means local, not network), and scope is marked S:U even though 'incorrect resource transfer between spheres' in a virtualization/multi-tenant vGPU context intuitively suggests crossing a trust boundary (guest→host or tenant→tenant); if NVIDIA's model treats the GPU manager and the attacker context as one authorization authority, S:U holds, but defenders in multi-tenant vGPU/VDI/cloud-GPU deployments should treat the cross-sphere aspect as the real concern. Verify the exact sphere boundary with NVIDIA bulletin 5861.

A low-privileged user or guest workload on a Linux host running the NVIDIA vGPU Virtual GPU Manager issues crafted requests that cause the manager to transfer a resource across a trust boundary it should not cross. By manipulating this resource handoff, the attacker corrupts manager state to execute code, escalate privileges, leak memory, or crash the service. No public exploit code has been identified at the time of analysis.