Quick Look: CVE-2026-119262, Improper Input Validation in Google Chrome V8 Allowing Code Execution Inside the Sandbox

Introduction

A High-severity input validation flaw in V8, the JavaScript and WebAssembly engine inside Google Chrome, allowed a crafted HTML page to potentially execute arbitrary code inside the browser's sandbox. The only delivery requirement is getting a user to load that page in an unpatched browser. Chrome held 68.79% of worldwide browser usage in October 2026 per Statcounter, so the fix in Chrome 156.0.8078.79 applies to a very large installed base. That share describes reach, not the number of vulnerable installs.

Technical Information

Root cause

NVD and Google classify CVE-2026-119262 as CWE-20: Improper Input Validation in V8. The official description reads: improper input validation in V8 in Google Chrome prior to 156.0.8078.79 allowed a remote attacker to potentially execute arbitrary code inside the sandbox via a crafted HTML page. Chromium rated it High.

V8's documented primary security goal is to execute untrusted JavaScript and WebAssembly safely. A validation gap on input that a web page controls therefore sits directly on the boundary V8 is designed to enforce.

We cannot tell you the exact defect. Chromium issue 574660146 returns an access-denied message, which is normal practice. Chromium keeps a security bug's tracker entry, including the linked V8 commit and regression test, closed until most users have the update. As a result, the public record does not identify:

• the vulnerable V8 function or tier (interpreter, optimizing compiler, runtime)
• the specific malformed input or JavaScript constructs needed
• the memory layout or exploit primitives involved

Any claim that this is a specific type confusion, bounds check elimination, or other named primitive would be speculation.

What a fix of this class usually looks like

Based on the bug class, V8 fixes for improper input validation usually add a missing check, at runtime or during optimization, on a value that originates from JavaScript before the engine relies on it. Typical examples are assumptions about a type, length, index, or object shape. If such an assumption is wrong, it can corrupt memory inside the renderer process, which fits the advisory's wording about executing code inside the sandbox. Google has not confirmed which component or check was changed.

CVSS interpretation

CISA ADP supplied the CVSS v3.1 score of 8.8. NVD has not published its own assessment. The vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H.

These values describe a severity assessment, not an observed attack. The explicit impact boundary in the official description remains the sandbox.

Attack flow

The publicly supported sequence is short:

1. A remote attacker prepares a crafted HTML page containing input that reaches the affected V8 processing path.
2. The attacker induces a user running Chrome earlier than 156.0.8078.79 to visit the page. Snyk describes this as enticing a user to visit a crafted page.
3. Chrome's renderer hands the page's script content to V8, where the input is not properly validated.
4. The disclosed potential outcome is arbitrary code execution inside the sandbox.

The disclosure does not establish a path from sandbox execution to host compromise. We recommend preserving that distinction when communicating impact internally.

Exploitation status

• Release reporting states Google has not reported exploitation of this issue.
• Tenable lists no known exploits available, and reviewed CVE reporting identifies no public proof of concept.
• The secondary tracker NotCVE marks the CVE as not in CISA KEV and not exploited in the wild. The CISA catalog material we reviewed did not independently confirm this CVE's status either way, so treat the NotCVE result as a tracker assessment.
• No threat actor, campaign, or CVE-specific indicator of compromise appears in the reviewed sources.

Because the tracker entry is restricted, the absence of public exploit details cannot rule out private exploit capability.

Timeline

Patch Information

Google fixed CVE-2026-119262 in the Chrome Stable and Extended Stable release of October 29, 2026:

• Windows and Mac: 156.0.8078.79/.80
• Linux: 156.0.8078.79

NVD lists the fix boundary as < 156.0.8078.79 and links two references: Google's release notes (tagged Release Notes / Vendor Advisory) and Chromium issue 574660146 (tagged Permissions Required). Tenable's plugin 373883 lists this CVE as Improper input validation in V8 with a patch publication date of 10/29/2026.

Why there is no diff

Bug 574660146 was still restricted when checked, so no public source shows the code change. No upstream result linked a verifiable V8 commit for this bug. One Chromium commit appeared in search results, but nothing ties it to this CVE, so we have left it out. Expect the commit to appear on chromium.googlesource.com (V8) once the bug is opened.

How the fix reaches users

Google Chrome. The V8 fix is compiled into the Chrome binary, so remediation means updating Chrome itself to 156.0.8078.79 or later, not updating a separate library. The same release fixed 20 other CVEs (21 in total), including issues in Skia, Frames, GarbageCollection, Dawn, and FileSystem. Google's documented update procedure:

1. Open Chrome.
2. Open the three-dot menu in the upper right corner.
3. Select Help > About Chrome to check the installed version and update status.
4. Close and reopen Chrome. Google states that an available update is applied when the browser is reopened, so this step is part of completing remediation.

Debian. The fix shipped in DSA-6605-1:

Gentoo. Bug 985241 tracks the release. Commit 0c32af148e5b updated www-client/google-chrome to 156.0.8078.79 on October 31, 2026. The same bug lists other Chromium-based packages: chromium, microsoft-edge, opera, opera-gx, vivaldi, and vivaldi-snapshot. Each receives the fix only when its vendor moves to a Chromium base that includes it.

No CVE-specific workaround or defensive configuration is documented. The only public patch is the Chrome 156.0.8078.79 release and the distribution packages built from it.

Detection Methods

Public detection for this CVE is about finding exposure, not catching exploitation. None of the reviewed sources publish exploit-specific IoCs, YARA or Sigma rules, or Snort or Suricata signatures. Detection means identifying endpoints still running a vulnerable V8 build.

Version checks on Windows and macOS

Tenable ships two local, credentialed Nessus plugins titled Google Chrome < 156.0.8078.79 Multiple Vulnerabilities:

Both read the installed version from the installed_sw/Google Chrome KB item and flag hosts below 156.0.8078.79. Each is a combined check for the October 2026 desktop advisory, so one finding covers this CVE alongside the Frames, Skia and GarbageCollection bugs fixed in the same release. Tenable states Nessus has not tested for these issues and relies on the application's self-reported version. In practice:

• A finding means the version is vulnerable, not that the host was attacked or that the bug is triggerable there.
• Coverage depends on inventory. Portable or per-user Chrome installs the scanner cannot enumerate will be missed.

If you build your own inventory queries in EDR, SCCM, Jamf, or osquery, treat anything below 156.0.8078.79 as exposed, and accept either the .79 or .80 build on Windows and Mac.

Package checks on Linux

On Linux, Chromium usually comes from distribution packages, so detection relies on package metadata. Tenable plugin 374257 (unpatched_CVE_2026_119262.nasl, family Misc., Unix agent) flags hosts with an affected package installed. It maps to Debian 12, 13 and 14 and the chromium package, requires local checks and the global_settings/vendor_unpatched setting, and relies on vendor-reported package presence.

Use the Debian security tracker to validate results manually. Given that bookworm was still marked vulnerable at review time despite the 156.0.8078.79-1~deb12u1 build, check the tracker directly rather than assuming that version string means a host is clean.

Limits and hunting notes

• With issue 574660146 restricted, the vulnerable code path and triggers cannot be verified, which is why no network or content signatures exist.
• A V8 exploit arrives inside ordinary, usually TLS-encrypted web content, making generic perimeter IDS rules a poor fit even after details become public.
• Without CVE-specific indicators, hunting falls back to general browser exploitation telemetry: unusual renderer crashes or unexpected child processes on hosts flagged by the version checks. Treat these as leads, not confirmed exploitation of this CVE.
• Rerun version and package checks after rollout. Chrome's staged rollout and lagging distro backports can leave hosts exposed well after the fix shipped.

Affected Systems and Versions

Both the Stable and Extended Stable channels received the fix. Other Chromium-based browsers tracked in Gentoo bug 985241 (Microsoft Edge, Opera, Opera GX, Vivaldi, Vivaldi snapshot) are fixed only once their vendors adopt a Chromium base that includes the change. No special configuration is required to be vulnerable. Under the published conditions, an affected build rendering a crafted page is sufficient.

Vendor Security History

Google runs the Chrome Vulnerability Reward Program, which offers monetary awards and public recognition for responsibly disclosed bugs. In its 2025 review, Google reports Chrome rewards totaling $3,716,750 paid to more than 100 reporters. SecurityWeek independently reported just over $3.7 million for Chrome, separate from Google's company-wide total.

The same review is useful context for V8 bugs specifically. It describes researchers finding holes in the V8 sandbox, including new classes of escape that the V8 team removed, and reports that hardening such as raw_ptr and object quarantining reduced reported sandbox escapes involving full exploit chains. It also notes researchers still demonstrated exploitation of Chrome IPC logic bugs. Nothing in the public record indicates that CVE-2026-119262 shares those mechanisms or bypasses the sandbox.

The release fixing this CVE addressed 21 vulnerabilities. Google's response can be measured by the published fixed version and release date. The initial report date is not public, so a remediation interval cannot be calculated.

References

• NVD: CVE-2026-119262
• CVE.org record: CVE-2026-119262
• CVE Services API record
• Chrome Releases: Stable Channel Update for Desktop (October 2026)
• Chromium issue 574660146 (restricted)
• Tenable Nessus plugin 373883 (Windows)
• Tenable Nessus plugin 373884 (macOS)
• Tenable Nessus plugin 374257 (Linux, unpatched package)
• Debian security tracker entry
• Gentoo bug 985241
• Red Hat CVE page
• Snyk advisory for Chromium
• NotCVE entry
• Casco CVE entry
• SecurityOnline: Chrome 156 security update
• Google: How to update Chrome
• V8 Sandbox README
• V8 Security Guidance
• CISA Known Exploited Vulnerabilities Catalog
• CISA KEV JSON feed
• Statcounter browser market share
• PiunikaWeb: Chrome desktop market share, October 2026
• Google Bug Hunters: Google VRPs in Review 2025
• Google Blog: VRP 2025 Year in Review
• Chrome Vulnerability Reward Program Rules
• SecurityWeek: Google bug bounty payouts in 2025