NVIDIA GPU Driver EUVD-2026-90143

Requires local access as an authenticated low-privileged user (PR:L) to a Linux host running the NVIDIA GPU Display Driver (GeForce, RTX/Quadro/NVS, or Tesla). The critical limiting prerequisite is that the signature-verification bypass only manifests 'under memory pressure' - the attacker must reliably induce a low-memory condition in the kernel at the moment verification occurs, a non-deterministic race-like state that makes exploitation opportunistic rather than dependable. There is no remote attack surface (AV:L) and no confidentiality impact; realistic risk is highest on shared/multi-tenant or VDI/cloud-GPU Linux hosts where untrusted low-priv users coexist.

This is a genuine but bounded-priority local vulnerability. The CVSS vector (AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H, 7.1 HIGH) confirms a locally-exploitable flaw requiring an already-authenticated low-privileged user (PR:L) on a Linux host running the NVIDIA GPU Display Driver, with no network reachability - so it cannot be triggered remotely and is not internet-exposed. No EPSS score, CISA KEV listing, or POC is present in the provided data, so there is no evidence of active exploitation or public exploit code; exploitation likelihood should be treated as low/targeted rather than widespread. A notable nuance: the description conditions the signature-verification bypass on 'memory pressure,' which is a non-deterministic trigger state the attacker must induce, making reliable exploitation harder than the vendor's AC:L rating implies - I would argue AC:H is more defensible (lowering my recomputed score to ~6.7). Impact is correctly integrity+availability only (C:N): a bypassed cryptographic signature check permits loading/accepting tampered content (I:H) and can crash the driver (A:H), but does not by itself disclose data. No vendor/NVD conflict on vendor, product, or platform; the only metadata problem is a mislabeled 'Jwt Attack' tag.

A low-privileged local user on a Linux workstation or shared GPU/VDI host deliberately drives the system into a low-memory condition, then submits data (e.g., firmware/microcode or other signed content) to the NVIDIA kernel-mode layer at the moment signature verification fails open. The driver accepts the unsigned/tampered payload (data tampering) or faults under the induced pressure (denial of service). No public exploit code is identified at time of analysis, and the memory-pressure dependency makes the timing non-trivial.