Chrome December 2025 Patch: WebGPU UAF and V8 OOB Fixes (CVE-2025-14765/14766)

  • Thread Author
Google’s December stable update corrected two high‑severity Chromium issues — a use‑after‑free in WebGPU (CVE‑2025‑14765) and an out‑of‑bounds read/write in V8 (CVE‑2025‑14766) — and the fixes were rolled into Chrome stable (143.0.7499.146/.147), with downstream consumers such as Microsoft Edge expected to ingest the upstream changes on their own release cadence.

Chrome security shield and tools guard a V8 engine against CVE-2025-14765 and CVE-2025-14766.Background / Overview​

Chromium is the shared open‑source engine that powers Google Chrome and numerous downstream browsers and runtimes. When Google assigns a CVE and ships an upstream fix in Chrome, the patch protects Chrome users immediately after update — but every downstream product that embeds Chromium must ingest the same upstream changes, build and test them, and then ship its own update. That downstream ingestion step is the operational gating item for Microsoft Edge and other Chromium‑based applications. Enterprise administrators therefore need two confirmations to be confident: (1) the upstream Chrome build that contains the fix; and (2) the downstream vendor build that explicitly ingests that upstream fix. Chromium’s public release note for the December 16 stable update lists both CVE‑2025‑14765 and CVE‑2025‑14766 as security fixes in the 143.0.7499.146/.147 family. Notably, Chrome’s release text identifies CVE‑2025‑14765 as the WebGPU use‑after‑free and CVE‑2025‑14766 as an out‑of‑bounds read/write in V8; this distinction matters because initial summaries — and downstream catalogs — sometimes conflate CVE numbers and descriptions. Administrators should verify the precise CVE ↔ component mapping before concluding which subsystem is affected in their environment.

What exactly changed (technical summary)​

CVE‑2025‑14765 — Use‑after‑free in WebGPU (Chromium)​

  • Class: Use‑after‑free (CWE‑416).
  • Component: WebGPU / Dawn (Chromium’s WebGPU implementation).
  • Impact: Heap corruption reachable from web content; remote attacker can induce the condition by luring a victim to visit a crafted page, potentially enabling arbitrary code execution when combined with other exploitation primitives.
  • Upstream fix: Landed in Chrome stable 143.0.7499.146/.147.
WebGPU exposes low‑level GPU functionality to web pages. Memory‑safety defects in GPU mediation code are especially sensitive because they often interface with GPU drivers and native platform libraries that can amplify exploitation possibilities or be used to pivot out of browser sandboxes.

CVE‑2025‑14766 — Out‑of‑bounds read/write in V8 (Chromium)​

  • Class: Out‑of‑bounds read/write (CWE‑787/CWE‑125, as applicable).
  • Component: V8 JavaScript engine (JIT/engine internals).
  • Impact: Heap corruption reachable via crafted HTML/JavaScript; similarly attractive to exploit developers because V8 memory primitives can be escalated into reliable read/write primitives, address leaks, or code execution.
  • Upstream fix: Included in the same Chrome stable roll (143.0.7499.146/.147).
V8 vulnerabilities have a known operational history of being weaponized quickly; when a V8 bug produces out‑of‑bounds memory access it becomes a highly attractive target for exploit chains that aim to escape sandboxing.

Verification and cross‑checks performed​

To produce a reliable advisory and avoid repeating mislabeling:
  • Google’s official Chrome Releases entry for December 16, 2025 was inspected to confirm the two CVE entries and the stable build family numbers (143.0.7499.146/.147). That upstream announcement names CVE‑2025‑14765 as WebGPU UAF and CVE‑2025‑14766 as a V8 OOB read/write.
  • National vulnerability registries and independent trackers (NVD, CVE Details, Tenable/Wiz summaries) were consulted to confirm the CVE IDs, the vulnerability classes, and the same upstream remediation boundary (Chrome prior to 143.0.7499.147). These independent records mirror Chrome’s release note and show the NVD entries published/updated on December 16, 2025.
  • Internal practice guidance and downstream ingestion discussion (how Edge consumes Chromium fixes and the ingestion lag risk) were cross‑checked against WindowsForum archive notes and established operational guidance that Microsoft publishes for Edge ingestion tracking. This confirms that Edge will be remediated only once Microsoft lists the ingesting Edge build in its Security Update Guide.
Caveat: Microsoft’s MSRC web UI requires JavaScript to render the interactive Security Update Guide page; the canonical downstream ingestion record is the SUG entry for CVE‑2025‑14766 (and CVE‑2025‑14765). Administrators should consult the MSRC Security Update Guide and Edge release notes to confirm the exact Edge build that ingests Chromium 143 changes before claiming Edge is remediated.

Why GPU and V8 bugs are high priority​

  • Surface and reach: Both WebGPU and V8 execute content that originates from untrusted web pages. The attack vector is Network with low attacker prerequisites beyond user navigation.
  • Exploit potential: GPU mediation code (WebGPU) interacts with drivers and native libraries, which often provide useful primitives for sandbox escape. V8 flaws enable JIT/engine‑level corruption that attackers commonly turn into robust memory primitives.
  • History: V8 memory‑safety defects and GPU‑facing bugs have historically been exploited by both private exploit vendors and state‑level actors; they are triaged as high or critical by vendors and tracking services.
Given that a single crafted page can trigger these classes of bugs, the risk model for most organizations is severe: denial‑of‑service, theft of web session material, or full native compromise if sandbox bypasses are chained.

Practical remediation checklist (immediate actions)​

  • Update Google Chrome on desktops and servers to the latest stable release in the 143.0.7499.146/.147 family and restart the browser to ensure the patched binary is running. Chrome’s About page will trigger and install updates.
  • For Microsoft Edge users:
  • Do not assume Edge is safe immediately after Chrome patches. Confirm that Microsoft has ingested Chromium 143 into the specific Edge build installed in your environment by checking the Microsoft Security Update Guide or Edge release notes.
  • Use edge://version and edge://settings/help to read the local build and compare it to the ingestion record in Microsoft’s SUG.
  • Inventory all embedded Chromium runtimes (high‑risk blind spots):
  • Electron apps (Slack, Discord variants, many internal apps)
  • Headless Chromium used in CI/CD or server rendering
  • Kiosk appliances, thin clients, and device management consoles
    These often do not auto‑update and remain vulnerable until their packager rebuilds them with patched Chromium.
  • Force a managed browser relaunch after update distribution; many endpoints remain exposed until the process restarts.
  • If you cannot immediately patch every endpoint, apply compensating controls:
  • Block or filter access to risky domains and known malvertising networks.
  • Restrict web browsing from privileged accounts; use a separate hardened browser or a jump host for admin tasks.
  • Temporarily disable features that are directly implicated (for example, WebGPU feature flags) only after testing for business impact and compatibility.
  • Tune detection and hunting:
  • Monitor EDR/telemetry for sudden renderer/GPU process crashes or anomalies tied to chrome.exe or msedge.exe.
  • Hunt for anomalous child process creation and suspicious heap‑corruption exceptions observed in endpoint logs.
  • Communicate: inform users and app owners about the urgency, and require rapid update/validation for high‑risk groups.

Enterprise verification steps (auditable, step‑by‑step)​

  • Export current browser versions across your estate (Intune, SCCM, Jamf or MDM). Record both the visible Edge/Chrome version and the underlying Chromium revision where possible (edge://version / chrome://version).
  • Look up the MSRC Security Update Guide entries for CVE‑2025‑14765 and CVE‑2025‑14766 to find the Edge build that ingests Chromium 143 changes.
  • Mark endpoints with Edge builds equal to or newer than the listed ingest build as remediated; everything older remains at risk.
  • Scan for packaged Electron binaries and headless Chromium containers; request patched packages from vendors or rebuild internal artifacts with the patched Chromium.
  • After patch rollout, validate by confirming:
  • Crash telemetry referring to affected components has dropped.
  • No new exploit indicators or suspicious child process patterns appear.
This verification mapping — local build string versus vendor ingestion entry — is the single most reliable indicator of downstream safety.

Detection, hunting, and forensics guidance​

  • Prioritize hunts for renderer or GPU process crashes clustered in particular user cohorts or after visits to specific domains.
  • Look for spikes in renderer process restarts, anomalous heap corruption exceptions, or sandbox escape attempts in EDR logs.
  • Correlate browser crash events with web access logs to prioritize domains for blocking or investigation.
  • Preserve memory images from suspected compromised endpoints for offline analysis; JIT and GPU‑related exploits sometimes leave telltale heap patterns.

Critical analysis — vendor response, strengths and residual risks​

Strengths​

  • Timely upstream remediation: Google published a stable channel update and grouped multiple fixes into the Chrome 143 promotion, making an upstream remediation boundary clear.
  • Public CVE tracking: Registries such as NVD and independent trackers rapidly mirrored the CVE records, providing multiple reference points for administrators to validate the fixes.
  • Established downstream process: Microsoft formally records Chromium CVEs in its Security Update Guide and Edge release notes so enterprise customers can verify whether Edge has ingested the fixes—this supports auditable patching and compliance workflows.

Residual risks and weaknesses​

  • Downstream ingestion lag: The window between Chrome patch publication and downstream products shipping their own patched binaries remains the single largest operational risk. Enterprises must track vendor ingestion rather than assuming immediate parity.
  • Embedded/packaged Chromium blind spots: Electron apps, headless Chromium containers, kiosk systems, and other bundled runtimes frequently require manual rebuilds and updates. These are persistent blind spots in many estates.
  • Exploit uncertainty: As of the cross‑checks performed, there was no authoritative, public confirmation that CVE‑2025‑14765 or CVE‑2025‑14766 were being actively exploited in the wild. Absence of proof‑of‑concept or in‑the‑wild confirmation does not reduce the urgency: both classes of bugs historically have been weaponized quickly when exploit primitives exist. Flagging of exploitation status should be handled conservatively and only adjusted when vendor telemetry or government KEV/ICS advisories confirm exploitation.

Special notes and verification caveats (what to watch for)​

  • Some public summaries and bug trackers may accidentally swap CVE IDs, descriptions, or component names. The canonical upstream reference for Chromium CVEs is the Chrome Releases post and Chromium issues; the canonical downstream confirmation for Microsoft Edge is the Microsoft Security Update Guide. Always cross‑check both.
  • The MSRC SUG UI is interactive and sometimes requires JavaScript; for automation, use the SUG API or vendor release note archival pages to retrieve ingestion records programmatically.
  • CVSS scores and exploitability metrics may vary among trackers; use multiple high‑quality sources (NVD, Tenable, vendor advisories) when compiling operational risk scores.

Recommended long‑term controls and best practices​

  • Maintain a comprehensive inventory of all Chromium instances across the organization, including embedded runtimes and server‑side rendering agents.
  • Enforce automatic updates for desktop browsers where feasible and accelerate test/pilot pipelines for critical patches.
  • Harden high‑value browsing: separate administrative browsing from general web browsing, restrict extensions, and use dedicated hardened profiles for high‑value accounts.
  • Employ runtime mitigations and exploit‑hardening where possible: enable ASLR, Control Flow Integrity (CFI), and other exploit mitigations supported by your OS and endpoint stack.
  • Make vendor ingestion checks part of your standard vulnerability closure workflow: track upstream fixes and downstream ingests as separate datapoints in ticketing and remediation trackers.

Conclusion​

The December Chrome stable update consolidated two high‑severity fixes — a WebGPU use‑after‑free (CVE‑2025‑14765) and an out‑of‑bounds read/write in V8 (CVE‑2025‑14766) — into Chrome 143.0.7499.146/.147. Administrators must update Chrome immediately and verify that their downstream Chromium consumers — notably Microsoft Edge and any embedded Chromium runtime — have ingested the same upstream fix before declaring systems remediated. Rapid inventory, vendor‑ingest verification, forced relaunches, and targeted compensating controls for high‑risk endpoints constitute the most effective operational approach while ingestion and distribution complete. Stay pragmatic: treat web‑reachable memory‑safety defects as urgent remediation items, confirm downstream ingestion from vendor advisories, and prioritize inventory and remediation of embedded Chromium runtimes that do not auto‑update.

Source: MSRC Security Update Guide - Microsoft Security Response Center
 

Back
Top