Google Chrome
CVE-2025-14765
HIGH
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessLure victim to crafted HTML page
-
DeliveryMalicious JS drives WebGPU API calls
-
ExploitTrigger use-after-free / heap corruption
-
ExecutionGroom heap and gain control
-
ImpactExecute attacker code in renderer
Vulnerability Assessment
| Weakness |
CWE
ASVS 5.0
V15 - Secure Coding and Architecture Memory lifecycle management
MITRE ATT&CK
2 techniques across 2 tactics: Execution, Privilege Escalation The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Exploitation requires the victim to use a vulnerable Chrome build (prior to 143.0.7499.147) and to visit an attacker-controlled or compromised web page that exercises the WebGPU API (UI:R - user must navigate/open the page). WebGPU must be reachable in the victim's browser (it is enabled by default in recent Chrome on supported hardware/platforms). No authentication is required (PR:N). Practical limiting factors: the bug lands in the sandboxed renderer process, so full-system compromise generally needs an additional sandbox-escape chain; user interaction (page visit) is mandatory; and patched or non-WebGPU-capable configurations are not exploitable. |
| Impact | This is a genuine high-priority issue driven primarily by product footprint rather than confirmed exploitation. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H, 8.8) indicates network-reachable, low-complexity, unauthenticated exploitation requiring only that a victim visit a malicious page - a realistic and low-friction condition for a browser. Against this, no EPSS score, no CISA KEV listing, and no public POC were provided, so there is no evidence of active or automated exploitation at time of analysis. The vector's C:H/I:H/A:H reflects the browser-CVSS convention of scoring full compromise; in practice a WebGPU renderer-process UAF yields heap corruption inside the sandboxed renderer, and weaponizing it into full code execution typically requires chaining a sandbox escape - a nuance not captured by the raw 8.8. No SSVC decision data was supplied. Net: a real patch-now item because of Chrome's ubiquity and the trivial delivery vector, but currently opportunistic/theoretical rather than confirmed in-the-wild. |
| Exploit ScenarioDerived | An attacker hosts or compromises a web page containing malicious JavaScript that drives the WebGPU API to trigger a use-after-free, corrupting heap memory in Chrome's renderer process. A victim running a pre-143.0.7499.147 Chrome merely visits the page (UI:R), and the attacker leverages the resulting heap corruption toward code execution. No public exploit code was identified at time of analysis. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Sep 30, 2026
Heap corruption via use-after-free in Google Chrome's WebGPU implementation (CWE-416) affects all builds prior to 143.0.7499.147, allowing a remote, unauthenticated attacker to corrupt memory in the renderer process when a victim simply visits a crafted HTML page that exercises the WebGPU API. No public exploit code has been identified at time of analysis and there is no confirmed active exploitation (CISA KEV) - the priority here is driven by Chrome's enormous deployment footprint and by the fact that exploitation needs only user interaction (UI:R) with no credentials (PR:N). Google rates the issue as High severity and has shipped a fixed build in the stable channel, and because the flaw lands in the sandboxed renderer, full host compromise would still require chaining an additional sandbox escape.
RemediationAI
Vendor-released patch: 143.0.7499.147 - upgrade Google Chrome to 143.0.7499.147 or later via the stable channel (see https://chromereleases.googleblog.com/2025/12/stable-channel-update-for-desktop_16.html), and ensure the browser process is fully restarted so the new build actually takes over, since Chrome will otherwise keep running the vulnerable binary until all windows and background processes are terminated. Enterprise fleets should force the update through the Google Update/Chrome Enterprise policies and verify reported versions rather than relying on auto-update. Where immediate upgrade is impossible, the most direct compensating control is to remove the attack surface by disabling WebGPU - via the chrome://flags WebGPU toggle where exposed, or an equivalent enterprise policy on managed endpoints - accepting that this breaks or degrades WebGPU-accelerated web applications and games for those users; note this is a mitigation, not a fix, and the browser remains vulnerable to other renderer bugs. Additional hardening worth applying while unpatched: keep the renderer sandbox intact and avoid disabling it (the bug is renderer-side, so the sandbox is the primary barrier to full compromise), restrict users to allowlisted sites through URL filtering to reduce exposure to attacker-controlled pages, and monitor for the Chromium issue (https://issues.chromium.org/issues/448294721) and any later stable-channel advisories in case the fix is revised or extended.
Affects your stack
Find out whether the stacks and servers you run are on an affected version.
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The root cause is a use-after-free (CWE-416) in Chrome's WebGPU implementation, the browser's modern graphics/compute API that exposes GPU hardware to web content through the Dawn/WebGPU stack. A use-after-free occurs when an object - here a WebGPU-related resource or GPU command structure - is freed while a reference to it remains live; a crafted HTML/JavaScript page can then drive the allocator to reuse the freed block, producing attacker-influenced heap corruption that can lead to arbitrary read/write or code execution inside the renderer process. Because the flaw sits in renderer-side WebGPU code, exploitation is constrained by the process sandbox, so a full-system compromise typically requires chaining a separate sandbox-escape vulnerability. The affected CPE is cpe:2.3:a:google:chrome:*:*:*:*:*:*:*:*, i.e. any Chrome version below the fixed 143.0.7499.147 build; the assessed vector CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H confirms network-reachable, unauthenticated exploitation gated only on the victim navigating to an attacker-controlled or compromised page on a WebGPU-capable configuration (WebGPU is enabled by default in recent Chrome on supported hardware and platforms).
Know when the next one hits your stack
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
Remote crafted page (AV:N), no privileges, user must visit (UI:R); adopting Chrome's convention of scoring renderer memory corruption as high C/I/A, matching the vendor vector.
Primary rating from Vendor (google).
CVSS VectorVendor: google
DescriptionCVE.org
Use after free in WebGPU in Google Chrome prior to 143.0.7499.147 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High)
Executive ViewAI
Google Chrome's WebGPU implementation contains a high-severity memory-corruption flaw (CVE-2025-14765) affecting all builds prior to 143.0.7499.147. An unauthenticated remote attacker can trigger the issue when a user visits a crafted HTML page, although no public exploit code has been identified at time of analysis; because the flaw resides in the sandboxed renderer, full host compromise would require an additional sandbox escape. Leadership should prioritize remediation given Chrome's broad enterprise footprint and the low-complexity user-interaction vector.
Apply vendor patch.
Threat Intelligence Overview
NVD
CVE.org
EPSS
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Use-after-free vulnerabilities occur when a program continues to access memory through a pointer after that memory has been deallocated.
Memory corruption occurs when a program writes data beyond the boundaries of allocated memory regions or accesses memory in unintended ways, violating the integrity of the process's address space.
Denial of Service attacks render applications or systems unavailable by overwhelming resources or triggering failure conditions.
Affected Products (CPE)CVE.org
Same weakness CWE-416 – Use After Free
View allSame technique Denial Of Service
View allVendor StatusVendor
SUSE
Severity: Important| Product | Status |
|---|---|
| SUSE Package Hub 15 SP6 | Fixed |
| SUSE Package Hub 15 SP7 | Fixed |
| openSUSE Leap 15.6 | Fixed |
| openSUSE Leap 16.0 | Fixed |
| openSUSE Tumbleweed | Fixed |
| SUSE Package Hub 15 SP7 | Affected |
| SUSE Package Hub 15 SP6 | Affected |
GitHub PoC
Exploit-DB