EUVD-2026-40774
GHSA-qp3w-hw9g-27h5
Severity by source
Sources disagree (Low–High)AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
Requires a pre-compromised renderer (modeled as PR:L) plus added exploitation effort and user navigation, so AC:H and UI:R; heap corruption yields total impact (C/I/A:H).
vuln.today treats the vendor’s rating as authoritative. A higher third-party CVSS (e.g. CISA-ADP) is shown for transparency but does not drive the headline severity.
CVSS VectorVendor: google
Lifecycle Timeline
4DescriptionCVE.org
Heap buffer overflow in WebNN in Google Chrome on Windows prior to 150.0.7871.47 allowed a remote attacker who had compromised the renderer process to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: Low)
AnalysisAI
Heap corruption in Google Chrome's WebNN (Web Neural Network API) implementation on Windows, fixed in 150.0.7871.47, lets an attacker who has already compromised the renderer process trigger a heap buffer overflow via a crafted HTML page and potentially escalate beyond the sandbox. Chromium's own security team rated this Low severity, while NVD scores it 8.8; EPSS is low at 0.19% (9th percentile) and there is no public exploit identified at time of analysis. It is not listed in CISA KEV and SSVC records exploitation status as none.
Technical ContextAI
The flaw resides in WebNN, Chrome's Web Neural Network API that exposes hardware-accelerated machine-learning graph execution to web content, running in the browser's rendering pipeline. The root cause is classified as CWE-20 (Improper Input Validation), which here manifests as a heap buffer overflow: malformed or crafted input to the WebNN graph is not properly validated, causing an out-of-bounds write on the heap. Affected builds are the Windows Chrome desktop channel prior to 150.0.7871.47 (Chromium-based); the CPE-equivalent scope from EUVD is Chrome versions below 150.0.7871.47. Because WebNN executes as part of the constrained renderer context, exploitation presupposes prior control of that process, making this a sandbox-boundary/heap-corruption primitive rather than an initial-access bug.
RemediationAI
Vendor-released patch: update Google Chrome to 150.0.7871.47 or later on Windows via the Stable channel update described at https://chromereleases.googleblog.com/2026/06/stable-channel-update-for-desktop_0175352312.html, then relaunch the browser to apply it - this is the primary and complete fix. In managed environments, push the update through your enterprise update policy and confirm end users restart Chrome so the new binary loads. As an interim compensating control before patching, you can disable the WebNN feature (for example via the corresponding chrome://flags entry or an enterprise policy that turns off experimental web-platform/WebNN features) to remove the vulnerable code path, at the cost of breaking any web apps that rely on hardware-accelerated neural-network inference. Because exploitation requires a pre-compromised renderer, keeping site isolation and the sandbox enabled and staying current on Chrome also limits the practical attack surface.
Same weakness CWE-20 – Improper Input Validation
View allSame technique Buffer Overflow
View allVendor StatusVendor
SUSE
Severity: Important| Product | Status |
|---|---|
| SUSE Package Hub 15 SP7 | Fixed |
| openSUSE Tumbleweed | Fixed |
| SUSE Package Hub 15 SP7 | Affected |
Share
External POC / Exploit Code
Leaving vuln.today