Mesa EUVD-2026-21737

Exploitation requires that the target actually exposes Mesa's WebGPU implementation to an untrusted party - the description states the allocation size 'depends on an untrusted party' and is used for alloca, so the concrete prerequisite is a deployment where WebGPU workloads from web content, a sandboxed application, or a guest VM are processed by a vulnerable Mesa (before 25.3.6, or 26.0.0-26.0.1). Limiting factors: systems that do not use Mesa's WebGPU path are not reachable, and reaching the code realistically involves the victim loading attacker-controlled WebGPU content, which implies attacker-supplied input and likely user interaction despite the NVD UI:N marking. The NVD vector claims no authentication (PR:N) and no interaction, but the WebGPU-untrusted-party framing means practical exploitation is gated on a WebGPU-enabled configuration rather than any default Mesa install.

The signals diverge sharply and should be weighed rather than averaged. The NVD CVSS vector (AV:N/AC:L/PR:N/UI:N) and 9.8 score imply trivial remote, unauthenticated, no-interaction exploitation with high confidentiality, integrity, and availability impact, and CISA SSVC agrees the technical impact is 'total'. Against that, SSVC records Exploitation as 'none' and Automatable as 'no', EPSS is only 0.04% (13th percentile), the CVE is NOT in CISA KEV, and no POC is referenced - so current real-world exploitation pressure is very low (no public exploit identified at time of analysis). There is also tension in the vector itself: WebGPU is normally reached by loading attacker-controlled content (a web page or a malicious guest), which realistically implies some user interaction or a specific WebGPU-enabled deployment rather than the pure UI:N/PR:N drive-by that AV:N/AC:L suggests - verify true reachability against Mesa merge request 39866. Net: this is a genuine memory-corruption bug worth patching promptly wherever WebGPU is exposed, but the 9.8 overstates near-term operational risk given low EPSS, no KEV, and SSVC 'Exploitation: none' / 'Automatable: no'.

An attacker gets a target to process attacker-controlled WebGPU content - for example a malicious web page or a hostile VM guest - that issues a crafted WebGPU request whose declared size drives Mesa's alloca allocation. The attacker-influenced size triggers an out-of-bounds write on the stack, corrupting memory to crash the process or potentially steer execution. No public exploit code is identified at time of analysis, and the AC:L rating suggests the trigger itself is not complex once a WebGPU path is reachable.