Brief Summary: Google Chrome Dawn WebGPU Memory Corruption (CVE-2026-119264) Allowing Sandboxed Code Execution

Introduction

A memory corruption flaw in Dawn, the WebGPU implementation that sits underneath Chromium, gave remote attackers a potential path to arbitrary code execution inside Chrome's sandbox using nothing more than a crafted HTML page. Statcounter put Chrome at 68.79% of worldwide browser share in October 2026, so most teams run the affected product. The practical question is whether every installation has actually updated and relaunched to 156.0.8078.79 or later.

Google rates CVE-2026-119264 as High severity, and CISA ADP assigned a CVSS 3.1 score of 8.8 (NVD has not published its own assessment). Two boundaries matter when you communicate this one internally. The documented impact is code execution inside the sandbox, not a sandbox escape or operating system compromise. And as of our review (November 3, 2026), there is no confirmed in-the-wild exploitation, public proof of concept, or threat actor attribution.

Technical information

Where Dawn sits

Dawn is Google's open-source, cross-platform WebGPU implementation and is Chromium's underlying WebGPU engine. It takes GPU commands produced by web content and turns them into calls to native graphics APIs. According to Dawn's own documentation:

• The frontend performs state tracking and validation.
• The backends translate validated WebGPU operations to the platform graphics API.
• The wire implementation serializes commands on the client side and deserializes and validates them on the server side.

That layering is why a web page can reach Dawn at all. WebGPU is exposed to page content, and the commands it issues flow through Dawn's validation and translation paths. This describes the architecture only. No exploit path through it has been disclosed.

Root cause: what the public record establishes

MITRE defines CWE-119 as reading or writing outside a buffer's intended boundary, and classifies it at an abstract level. On its own it does not tell us whether this is a heap overflow, a stack overflow, a use-after-free, or what read or write primitive an attacker gets.

Given the classification, the fix most likely adds or corrects a bounds or size check before Dawn reads or writes a buffer. That is our inference. No code change for this CVE is public, the Chromium issue is tagged "Permissions Required" in NVD, and Chromium typically keeps security bugs and their linked commits private until most users have the fix. The record does not name the specific WebGPU call, shader, graphics backend, command validation failure, or function involved. For that reason, this post contains no vulnerable code.

Severity vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

The user interaction requirement reflects the delivery mechanism: a victim has to load attacker-controlled content. The description does not specify a click sequence or permission prompt beyond that.

Attack flow

Based on the published description and scoring, exploitation would proceed along these lines:

1. The attacker hosts or injects a crafted HTML page.
2. A user with an affected Chrome build (before 156.0.8078.79) loads the page. No privileges or prior access are needed.
3. Content on the page drives work that Dawn processes as it validates and translates WebGPU commands into native graphics API calls.
4. A memory operation in Dawn crosses the bounds of a buffer, corrupting memory.
5. The attacker uses that corruption to potentially execute arbitrary code inside the sandbox. Scope is rated Unchanged, so the documented impact stays within that security boundary.

Reaching the underlying operating system would require a separate sandbox escape, and nothing in the public record ties one to this CVE.

Exploitation status

TheHackerWire also shows a "30 day in the wild exploitation forecast" field. A forecast is not an observed incident. Release coverage noting that Google had not reported exploitation applies to the Chrome 156 release bundle as a whole, not to a dedicated investigation of this flaw.

Patch information

Google fixed CVE-2026-119264 in the Chrome 156 Stable Channel update released on October 29, 2026:

• Windows and Mac: 156.0.8078.79/.80
• Linux: 156.0.8078.79
• The same update went to the Extended Stable channel.

Google's CNA record marks every Chrome build earlier than 156.0.8078.79 as affected, so that version is the first fixed one. The CNA lists two references: the release blog post and Chromium issue 575150692.

One fix among many

The Dawn fix is not separately installable. Gentoo's tracking bug for this release lists 21 CVEs, including CVE-2026-119264 ("Memory corruption in Dawn"), alongside bugs in V8, Skia, Quota, Blink and FileSystem. You get the Dawn fix by moving to a Chrome 156 build at or above 156.0.8078.79.

Downstream packages

Gentoo's bug also lists chromium, microsoft-edge, opera, opera-gx, vivaldi and vivaldi-snapshot, since those browsers share the Chromium code that contains Dawn.

One caveat on Snyk's Debian 12 Chromium entry: it says no fixed package version is listed there, and its default Low-severity label is not evidence that Google downgraded this High-severity CVE. Do not substitute the upstream Chrome version number for package-specific status.

Completing the update

Downloading an update does not apply it. Google's documentation says explicitly that a pending update requires a relaunch.

• Check the version: Chrome menu, Help > About Chrome.
• Apply it: use Relaunch to Update, or close and reopen Chrome.
• Verify the full four-part string: a 156.x build is fixed only at 156.0.8078.79 or later. Earlier 156.0.8078.x builds are still vulnerable.
• Other Chromium-based browsers: confirm the vendor has pulled in the 156.0.8078.79 Chromium base. The Chrome version number alone does not tell you that.

For managed fleets, the relaunch notification policy is the deciding control:

• Relaunch recommended: users can dismiss the notification and keep using the old browser indefinitely.
• Relaunch required: recurring notifications instruct users to relaunch within a set period, and the admin console can force relaunch after that period.

Google also recommends keeping automatic updates enabled through enterprise policy, and you can confirm applied policies at chrome://policy using Reload policies. No CVE-specific configuration workaround or exploit-blocking rule has been documented, so the update plus relaunch is the remediation.

Detection methods

For this CVE, detection means finding exposure rather than catching exploitation. None of the sources we reviewed publish exploitation IoCs, YARA or Sigma rules, or Snort/Suricata signatures, so the work comes down to finding every vulnerable Chrome or Chromium build in the environment.

1. Version boundary

NVD's affected configuration:

cpe:2.3:a:google:chrome:*:*:*:*:*:*:*:*  (up to, but not including, 156.0.8078.79)

Treat any desktop Chrome below 156.0.8078.79 as vulnerable. Inventory sources (EDR software inventory, MDM, SCCM/Intune, osquery-style asset queries) need to capture the full four-part version string, because the major version alone does not indicate patch status. Chrome normally updates itself, so focus on where that breaks down:

• Long-running sessions that have staged an update but not relaunched
• Machines where policy blocks updates
• Offline systems and VDI golden images

2. Tenable Nessus plugin 374238 (Debian Chromium)

Plugin 374238, Linux Distros Unpatched Vulnerability : CVE-2026-119264 (unpatched_CVE_2026_119264.nasl, published 10/30/2026), has some prerequisites worth knowing before you rely on it:

• Local, credentialed check. It is typed as Local with a Unix agent, and requires KB items including Host/local_checks_enabled, Host/cpu and Host/OS/identifier. An unauthenticated network scan will not fire it. Use SSH credentials or a Nessus Agent. Supported sensors include Nessus, Nessus Agent, Agentless Assessment, Frictionless Assessment Agent, Tenable Cloud Security and Tenable's self-hosted container security product, so container images are covered.
• Vendor-unpatched family. It also requires global_settings/vendor_unpatched. If the scan policy does not enable reporting of vendor-unpatched vulnerabilities, the plugin stays silent even on affected hosts. It flags packages where the distribution has no patch available, and its references point to the Debian security tracker.
• Scope. CPEs cover Debian 12, 13 and 14 and p-cpe:/a:debian:debian_linux:chromium. The check relies on package presence as reported by the vendor, so a finding means the Chromium package is installed and on Debian's affected list, not that the host was attacked.

3. Rapid7

Rapid7's Vulnerability & Exploit Database lists CVE-2026-119264 as Covered by Rapid7 for Google Chrome (added October 30, 2026). InsightVM/Nexpose users should expect a version-based Chrome check mapped to upgrading Chrome.

Between the two, you cover both likely channels: Google-distributed Chrome on endpoints (Rapid7 or your own inventory comparison) and distro-packaged Chromium on Debian (Nessus 374238).

4. Using the signals

• Scanner hits indicate exposure only. A hit is not evidence of compromise, and a clean result does not rule out past exploitation.
• Correlate sources. A Linux host may pass a Chrome-focused check while running a Debian chromium package that 374238 flags, or the reverse.
• Prioritize browsers used for general web browsing in your rescan and verification cycle, since exploitation only needs a visit to a crafted page (AV:N/AC:L/PR:N/UI:R).
• Revisit periodically. Issue 575150692 is restricted, so technical details that could support behavioral detection may appear later in vendor plugin feeds or the CVE record.

Affected systems and versions

Other Chromium-based browsers tracked by Gentoo for this release (chromium, microsoft-edge, opera, opera-gx, vivaldi, vivaldi-snapshot) are affected until their vendors integrate the 156.0.8078.79 Chromium base. No specific vulnerable configuration beyond the version range has been documented.

Vendor security history

Google's review of its 2025 vulnerability reward programs gives useful context for how Chrome security works in practice:

• $3,716,750 in Chrome rewards paid to more than 100 reporters, including researchers who found holes in the V8 sandbox and helped remove new classes of escape.
• Memory safety measures including raw_ptr and object quarantining reduced reported sandbox escapes involving complete exploit chains.
• Even so, two researchers demonstrated exploitation of logic bugs in Chrome's interprocess communication mechanisms, earning $250,000 in rewards.

This is defense in depth with residual risk. The sandbox and memory defenses are meaningful, and exploitable bugs still get through. None of this history is evidence about CVE-2026-119264 specifically, and it supports neither complacency about sandboxed code execution nor an assumption that this Dawn flaw escapes the sandbox. The same Chrome 156 release also fixed a separate Critical issue. This CVE's rating is High.

References

• NVD: CVE-2026-119264
• CVE record (MITRE CVE API)
• Chrome Releases: Stable Channel Update for Desktop (October 2026)
• Chromium issue 575150692 (restricted)
• Snyk advisory for chromium (unmanaged)
• Snyk advisory for Debian 12 chromium
• Debian security tracker entry
• Gentoo tracking bug 985241
• Tenable Nessus plugin 374238
• Tenable CVE page
• Rapid7 Vulnerability & Exploit Database entry
• cvefeed.io entry
• TheHackerWire analysis
• SecurityOnline: Chrome 156 security update
• Dawn README
• Dawn architecture overview
• MITRE CWE-119
• Google: How to update Chrome
• Chrome Enterprise: Notify users to restart to apply pending updates
• Chrome Enterprise: Auto update policies
• Google VRPs in Review 2025
• Statcounter browser market share
• TechnologyChecker: Chrome market share Q3 2026