CVE-2026-10987 · Integer overflow in V8 in Google Chrome prior to 149.0.7827.53 allowed a remote attacker to execute arbitrary code inside a sandbox via a cr

01 · The Real Story

This is a burglar getting into the apartment lobby, not the penthouse

CVE-2026-10987 is described as an integer overflow in V8, Chrome's JavaScript engine, affecting Google Chrome versions prior to 149.0.7827.53. The stated outcome is arbitrary code execution *inside the Chrome sandbox* after a user is lured to attacker-controlled web content; the public description appears truncated, but Chrome V8 bugs of this class are typically triggered via a crafted HTML or script payload rendered by the browser.

Google's HIGH 8.8 baseline is understandable for a remote browser memory-corruption bug, but it overstates enterprise impact if read as host compromise. The decisive reality check is that the bug lands code execution in a renderer sandbox, not native OS-level execution, and there is no current KEV listing, no cited in-the-wild exploitation, and the provided EPSS signal is extremely low. That pushes this down from emergency to disciplined fleet hygiene.

"A web-triggerable V8 bug matters, but sandbox-only code execution without exploitation evidence is not an all-hands fire drill."

02 · The Attack Path

4 steps from start to impact.

STEP 01

Deliver attacker-controlled web content

The attacker needs the target to render hostile content in Chrome, typically via phishing, malvertising, a compromised site, or embedded third-party content. No authentication is required, but the victim must browse to or otherwise load attacker-influenced content.

Conditions required:

Target is using Chrome older than 149.0.7827.53
User loads a malicious or compromised page
Relevant V8 code path is reachable in the target build

Where this breaks in practice:

Requires user interaction or at least user browsing activity
Email filtering, safe browsing, URL isolation, and ad blocking reduce reach
Enterprise users on managed channels may auto-update quickly

Detection/coverage: Exposure is best detected by version inventory, not network scanning. Web proxies, Safe Browsing telemetry, and EDR/browser crash telemetry may show precursor activity, but they do not reliably prove exploit delivery.

STEP 02

Trigger the V8 integer overflow

The weaponized content abuses the V8 flaw to corrupt memory and redirect execution within the renderer process. In practice this means a precise exploit chain tailored to the vulnerable Chrome build and platform.

Conditions required:

Exploit is reliable against the victim's exact Chrome branch and OS
Mitigations in that build do not break the exploit primitive

Where this breaks in practice:

Browser exploit reliability is version-sensitive
Modern exploit mitigations and V8 hardening raise exploit development cost
Public root-cause details are restricted or absent, limiting commodity weaponization

Detection/coverage: Most scanners cannot validate exploitability beyond vulnerable version checks. Crash spikes in chrome.exe child processes or abnormal renderer terminations may be weak signals only.

STEP 03

Gain code execution in the renderer sandbox

Successful exploitation yields code execution inside Chrome's sandboxed renderer rather than direct execution on the host. That is still dangerous for browser-session abuse, but it is materially less severe than a browser-to-OS escape.

Conditions required:

Exploit succeeds fully rather than just crashing the renderer
Target browsing session holds content or tokens the attacker wants

Where this breaks in practice:

Sandbox boundaries constrain filesystem, process, and kernel reach
Impact may be limited to the compromised tab, site context, or renderer process
A second vulnerability is usually needed for host compromise

Detection/coverage: EDR can sometimes observe suspicious child-process behavior after a sandbox break attempt, but sandboxed renderer execution by itself is notoriously hard to distinguish from normal browser activity.

STEP 04

Attempt follow-on abuse or chain with a sandbox escape

To convert renderer execution into full workstation compromise, the attacker usually needs a second bug such as a sandbox escape, kernel privilege escalation, or broker-process issue. Without that second stage, blast radius is narrower and typically limited to browser-resident data and session abuse.

Conditions required:

Attacker has a second exploit or a worthwhile in-browser objective
Victim session contains accessible secrets or privileged web apps

Where this breaks in practice:

Second-stage exploits are rarer and more expensive
SSO protections, device-bound sessions, and conditional access can reduce post-exploit payoff
No public evidence currently ties this CVE to an active exploit chain

Detection/coverage: Detection quality improves only when the attacker attempts post-exploitation beyond the renderer, such as broker abuse, process injection, unusual child processes, or abnormal token use in SaaS logs.

03 · Intelligence Metadata

The supporting signals.

In-the-wild status	No public evidence found that `CVE-2026-10987` is being exploited in the wild, and it is not listed in CISA KEV as of this assessment.
Proof-of-concept availability	No public PoC or researcher repo was found for this specific CVE. That does not mean exploitation is impossible; it means current public weaponization signal is weak.
EPSS	User-supplied EPSS is `0.0008` (0.08%), which is very low. Per FIRST EPSS, this is a threat-likelihood input, not an impact measure.
KEV status	Not KEV-listed. No CISA due date applies from the catalog.
CVSS vector	`CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H` maps to remote, low-complexity, no-privilege exploitation with user interaction required. The real-world overstatement is the `H/H/H` impact tuple despite the public description saying execution is inside a sandbox.
Affected versions	Affected: Google Chrome prior to `149.0.7827.53`. Practically, your risky population is unmanaged or update-lagging desktop browsers, not internet-facing servers.
Fixed versions	Fixed in Chrome `149.0.7827.53` for the early stable rollout on Windows and Mac; `.54` is the paired Mac/Windows release notation in Google's post. No distro-style Linux backport data was found in the public references used here.
Scanning / exposure data	Shodan/Censys-style internet census is not useful here because this is a client-side browser flaw. Exposure must be measured from endpoint inventory, browser management telemetry, EDR software inventory, or Chrome enterprise reporting.
Disclosure date	User-supplied disclosure date: 2026-06-04. The visible early-stable version `149.0.7827.53/.54` was posted on May 29, 2026, which suggests fixes may have shipped before broad public detail.
Researcher / reporter	No public reporter attribution for this specific CVE was found in the sources reviewed. That is common for Chrome issues while bug details remain restricted.

04 · The Call

noisgate verdict.

Final Verdict

↓ DOWNGRADED to MEDIUM (6.4/10)

The single biggest severity reducer is that the published impact is code execution inside Chrome's sandbox, not verified host compromise. That means this CVE is dangerous as an initial browser foothold, but without a second-stage escape or active exploitation evidence it does not justify the same urgency as a one-bug workstation takeover.

HIGH Affected version boundary and fixed version (`149.0.7827.53`)

MEDIUM Practical exploit chain assessment based on public description only

MEDIUM Severity downgrade from vendor score due to sandbox-only stated impact

Why this verdict

Downgrade for sandbox-only impact: the public description says arbitrary code execution occurs *inside a sandbox*, which is materially below direct host RCE.
Downgrade for user-interaction dependence: this is a browser bug that still needs the victim to render attacker-controlled content, so reach depends on phishing, malvertising, or site compromise.
Downgrade for low threat signal: no KEV listing, no public in-the-wild reporting found, and the supplied EPSS 0.0008 is very low.
Baseline remains meaningful because exposure is broad: Chrome is ubiquitous and attacker-controlled web content is easy to deliver, so this is not LOW.
Exploit development is non-trivial in practice: renderer memory-corruption exploits are version-sensitive and modern V8/browser hardening increases real-world friction.

Why not higher?

To justify HIGH or CRITICAL here, I would want either evidence of active exploitation, a demonstrated sandbox escape chain, or a public description showing unsandboxed/native code execution on the host. We have none of those. The public description narrows impact to the renderer sandbox, which is exactly the kind of friction that should push a score down.

Why not lower?

This is still a remotely reachable browser memory-corruption bug in one of the most exposed applications in the enterprise. Attackers do not need credentials, and security controls do not reliably prevent a user from eventually loading hostile web content. Even sandboxed renderer code execution is too much attacker capability to dismiss as mere backlog noise.

05 · Compensating Control

What to do — in priority order.

Force browser auto-update compliance — Use Chrome enterprise policy, your software deployment platform, or EDR software management to ensure endpoints actually move to 149.0.7827.53 or later. For a MEDIUM noisgate verdict there is no mitigation SLA — go straight to the 365-day remediation window, but for browsers you should still clean up non-updating stragglers in the current maintenance cycle because exposure is universal.
Reduce untrusted web exposure — Tighten safe-browsing posture, DNS\/URL filtering, ad blocking, and remote browser isolation for high-risk user groups to reduce the chance of hostile content ever reaching a vulnerable renderer. This is a sensible risk reducer while patch coverage catches up; for MEDIUM, there is no noisgate mitigation SLA, so apply as standard hardening rather than emergency change.
Harden browser execution paths — Block unsupported extensions, restrict developer mode, and enforce exploit protection\/EDR policies around browser child-process behavior. These controls do not fix the bug, but they can reduce post-exploitation options if a renderer is compromised before the patch lands within the 365-day remediation window.
Prioritize high-risk user cohorts — Patch admins, finance, executives, developers, researchers, and users with heavy external web exposure first because they are the most likely to encounter targeted content. Even with a MEDIUM verdict, targeted-phishing populations deserve accelerated operational attention.

What doesn't work

Perimeter scanning won't help because this is not a server-side exposure you can find from the internet.
Network segmentation does little here because the initial trigger is normal outbound web browsing from the endpoint.
MFA does not prevent exploitation of the browser engine itself; it only helps limit some downstream account abuse.
Treating the sandbox as a complete defense is a mistake; it reduces impact, but it does not eliminate in-browser theft or follow-on chaining risk.

06 · Verification

Crowdsourced verification payload.

Run this on the target Windows endpoint or via your endpoint management tool as the logged-in user or an administrator; admin rights are not strictly required for local version checks. Invoke with powershell -ExecutionPolicy Bypass -File .\check-chrome-cve-2026-10987.ps1 and it will inspect common Chrome install locations and output VULNERABLE, PATCHED, or UNKNOWN.

noisgate-verify.ps1

POWERSHELLREAD-ONLYSAFE

# check-chrome-cve-2026-10987.ps1\n# Exit codes:\n#   0 = PATCHED\n#   1 = VULNERABLE\n#   2 = UNKNOWN\n\n$ErrorActionPreference = 'Stop'\n$fixedVersion = [version]'149.0.7827.53'\n\nfunction Get-ChromeVersion {\n    $candidates = @(\n        "$Env:ProgramFiles\\Google\\Chrome\\Application\\chrome.exe",\n        "$Env:ProgramFiles(x86)\\Google\\Chrome\\Application\\chrome.exe",\n        "$Env:LocalAppData\\Google\\Chrome\\Application\\chrome.exe"\n    )\n\n    foreach ($path in $candidates) {\n        if (Test-Path $path) {\n            try {\n                $item = Get-Item $path\n                if ($item.VersionInfo -and $item.VersionInfo.ProductVersion) {\n                    return [pscustomobject]@{\n                        Path = $path\n                        Version = $item.VersionInfo.ProductVersion\n                    }\n                }\n            }\n            catch {\n                continue\n            }\n        }\n    }\n\n    return $null\n}\n\ntry {\n    $chrome = Get-ChromeVersion\n\n    if (-not $chrome) {\n        Write-Output 'UNKNOWN: Google Chrome not found in common install paths'\n        exit 2\n    }\n\n    try {\n        $installedVersion = [version]$chrome.Version\n    }\n    catch {\n        Write-Output ("UNKNOWN: Unable to parse Chrome version '{0}' at {1}" -f $chrome.Version, $chrome.Path)\n        exit 2\n    }\n\n    if ($installedVersion -lt $fixedVersion) {\n        Write-Output ("VULNERABLE: Chrome {0} at {1} is older than fixed version {2}" -f $installedVersion, $chrome.Path, $fixedVersion)\n        exit 1\n    }\n    else {\n        Write-Output ("PATCHED: Chrome {0} at {1} is at or above fixed version {2}" -f $installedVersion, $chrome.Path, $fixedVersion)\n        exit 0\n    }\n}\ncatch {\n    Write-Output ("UNKNOWN: {0}" -f $_.Exception.Message)\n    exit 2\n}\n

07 · Bottom Line

If you remember one thing.

TL;DR

Monday morning: pull a version-based inventory of Chrome endpoints, confirm which systems are still below 149.0.7827.53, and use normal browser-update operations to close the gap. For this MEDIUM rating there is no noisgate mitigation SLA — go straight to the 365-day remediation window; use the noisgate remediation SLA to require the vendor-fixed browser version within <= 365 days, but in practice you should force auto-update validation this week and treat unmanaged or stuck browsers as the real problem to solve.

Sources

Peer Review

What defenders are saying.

Submit a review attribution: handle + country only

0 flags selected · stored anonymously

Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.