This is a break-in that gets the attacker into the lobby, not the data center
CVE-2026-10965 is an integer overflow in Chrome's DevTools code that affects Google Chrome versions prior to 149.0.7827.53; Google's June 2, 2026 desktop release notes show fixes in 149.0.7827.53 for Linux and 149.0.7827.53/54 for Windows and Mac. The public description says a remote attacker can trigger arbitrary code execution *inside a sandbox* via a crafted HTML page, which means the immediate win is code execution in a constrained browser process rather than direct operating-system compromise.
Google's HIGH 8.8 rating is technically fair if you score the memory corruption in isolation, but it overstates operational urgency for enterprise patch queues. The decisive friction is the sandbox boundary: without a second bug, the attacker does not get browser-level or host-level execution, and there is no current KEV listing, no public exploitation evidence, and only a very low reported EPSS signal.
4 steps from start to impact.
Land the victim on a malicious page
UI:R vector.- Victim is running Chrome older than
149.0.7827.53 - Victim opens attacker-controlled or attacker-influenced web content
- The vulnerable DevTools code path is reachable in that browsing context
- Email security, web filtering, Safe Browsing, and user behavior all cut into reachability
- Public details do not confirm whether any extra DevTools-specific condition is needed, which adds uncertainty for weaponization
Trigger the integer overflow
- A vulnerable build
- A working trigger for the specific DevTools overflow
- An exploitation path that survives allocator and compiler hardening
- No public PoC was found in primary sources
- Restricted bug details slow copycat exploit development
- Modern browser mitigations reduce exploit reliability
Gain execution inside Chrome's sandbox
- Step 2 succeeds
- The sandbox remains the attacker's current execution boundary
- Chrome's sandbox meaningfully limits direct filesystem, device, and privileged OS access
- Impact is closer to 'renderer/process compromise' than 'host takeover' absent a chain
Chain a sandbox escape for real host impact
- A separate sandbox escape, broker abuse, or OS-level weakness
- Ability to chain multiple exploit stages reliably on the victim platform
- Second-bug requirement sharply narrows real-world exploitability
- EDR, ASR, and exploit protection are more likely to break the chain at this stage
The supporting signals.
| In-the-wild status | No authoritative evidence of active exploitation found in the reviewed sources as of 2026-06-05; not listed in CISA KEV. |
|---|---|
| Public PoC / exploit code | No public PoC located in primary-source review. The Chromium issue exists but bug details are effectively restricted, which slows opportunistic weaponization. |
| EPSS | 0.0008 probability over 30 days from the user-provided intel, which is extremely low and consistent with a non-weaponized, non-KEV browser bug. |
| KEV status | No; no CVE-2026-10965 entry was found in CISA's Known Exploited Vulnerabilities catalog search results. |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H — network-reachable and low-complexity on paper, but UI:R plus sandboxed impact are the real brakes. |
| Affected versions | Chrome prior to 149.0.7827.53 per NVD. NVD's affected CPE analysis maps this to Chrome on Windows, macOS, and Linux. |
| Fixed versions | Desktop stable release on 2026-06-02: Linux 149.0.7827.53 and Windows/Mac 149.0.7827.53/54 according to Google's release post. |
| Disclosure / reporting | Vendor/NVD publication date: 2026-06-04. Google's release post says the issue was reported by Google on 2026-05-08. |
| Exposure / scanning reality | Internet-wide sources like Shodan/Censys/FOFA are not useful here because this is a client browser issue, not a server-exposed service. Use endpoint inventory, EDR, MDM, or enterprise browser management to find exposure. |
| Root-cause context | Mapped to CWE-472 External Control of Assumed-Immutable Web Parameter in the CVE record, but public technical detail is too sparse to validate exploit preconditions beyond the high-level description. |
noisgate verdict.
The single biggest severity reducer is that successful exploitation yields code execution inside Chrome's sandbox, not on the host. With no KEV listing, no public exploitation evidence, and no public chain to escape the sandbox, this is a browser memory bug you should patch through normal fleet hygiene rather than treat as an enterprise fire drill.
Why this verdict
- Vendor started at 8.8 HIGH; I cut it down because the published impact is sandboxed code execution, not host compromise
UI:Rmatters: this still needs the victim to hit attacker-controlled content, so it is not wormable or self-propagating inside the fleet- No active-exploitation signal: no KEV entry, no public PoC found, and the provided EPSS is extremely low
- Second-stage requirement is the killer friction: meaningful workstation takeover usually needs a separate sandbox escape or local privilege path
- Exposure population is broad but shallow: Chrome is everywhere, yet this is still a client-side browsing event, not an unauthenticated internet-facing server bug
Why not higher?
Because the public record explicitly stops at arbitrary code execution *inside a sandbox*. If you cannot cross the sandbox boundary with the same CVE, the blast radius is materially smaller than a browser-to-host RCE, and that matters more than the theoretical C:H/I:H/A:H values in the base vector.
Why not lower?
Because it is still a remote memory-corruption bug in the most widely deployed browser estate in most enterprises, and the trigger path is just web content. If an attacker later pairs it with a sandbox escape or if exploitation evidence appears, this would move up fast.
What to do — in priority order.
- Force browser auto-update compliance — Use enterprise browser policy, MDM, or software distribution to ensure Chrome moves to
149.0.7827.53+on Linux and149.0.7827.53/54+on Windows/Mac. For a MEDIUM verdict there is no mitigation SLA, so keep this as normal fleet hygiene and complete actual patching within the 365-day remediation window. - Block unmanaged Chrome versions from sensitive apps — Use conditional access, NAC posture checks, or app-proxy policy to deny risky browser builds access to high-value SaaS and admin portals. There is no mitigation SLA for MEDIUM, so this is optional risk reduction while patch rollout catches up rather than an emergency control.
- Tighten browser exploit guardrails — Verify Safe Browsing, site isolation defaults, exploit protection, ASR-style controls, and EDR browser hardening are enabled on managed endpoints. These do not fix the bug, but they raise attacker cost and buy resilience until patching is completed inside the 365-day remediation window.
- Inventory by version, not by installed-software name — Pull exact Chrome versions from EDR/MDM/browser management because traditional network vulnerability scanners have poor visibility into endpoint browser patch state. For this MEDIUM case, there is no mitigation SLA — go straight to the 365-day remediation window with accurate exposure data.
- A WAF does not help; this is not a server-side web app flaw and the exploit runs in the victim browser.
- Perimeter scanning does not meaningfully surface exposure because Chrome is a client application, not an internet-facing service.
- MFA is irrelevant to the exploit path; it may reduce downstream account abuse, but it does not stop memory corruption in the browser process.
- Antivirus signatures alone are weak coverage when there is no public exploit sample and the trigger is a crafted webpage.
Crowdsourced verification payload.
Run this on the target endpoint or through your fleet agent/EDR remote shell. Invoke it with python3 chrome_cve_2026_10965_check.py; it needs only standard user rights and checks installed Chrome version across Windows, macOS, and Linux, then prints VULNERABLE, PATCHED, or UNKNOWN.
#!/usr/bin/env python3
# CVE-2026-10965 Chrome version check
# Exit codes:
# 0 = PATCHED
# 1 = VULNERABLE
# 2 = UNKNOWN / Chrome not found / parse failure
import os
import platform
import re
import shutil
import subprocess
import sys
TARGET = (149, 0, 7827, 53)
MAC_WIN_ALLOW_54 = (149, 0, 7827, 54)
def parse_version(text):
m = re.search(r'(\d+)\.(\d+)\.(\d+)\.(\d+)', text)
if not m:
return None
return tuple(int(x) for x in m.groups())
def run_cmd(cmd):
try:
p = subprocess.run(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True, timeout=10)
out = (p.stdout or '') + '\n' + (p.stderr or '')
return out.strip()
except Exception:
return ''
def get_windows_version():
candidates = [
os.path.expandvars(r'%ProgramFiles%\Google\Chrome\Application\chrome.exe'),
os.path.expandvars(r'%ProgramFiles(x86)%\Google\Chrome\Application\chrome.exe'),
os.path.expandvars(r'%LocalAppData%\Google\Chrome\Application\chrome.exe'),
]
for path in candidates:
if path and os.path.exists(path):
out = run_cmd(['powershell', '-NoProfile', '-Command', f"(Get-Item '{path}').VersionInfo.ProductVersion"])
v = parse_version(out)
if v:
return v, path
return None, None
def get_macos_version():
path = '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'
if os.path.exists(path):
out = run_cmd([path, '--version'])
v = parse_version(out)
if v:
return v, path
return None, None
def get_linux_version():
candidates = ['google-chrome', 'google-chrome-stable', 'chromium', 'chromium-browser']
for name in candidates:
exe = shutil.which(name)
if exe:
out = run_cmd([exe, '--version'])
v = parse_version(out)
if v:
return v, exe
return None, None
def compare(v1, v2):
return (v1 > v2) - (v1 < v2)
def main():
system = platform.system().lower()
version = None
path = None
if 'windows' in system:
version, path = get_windows_version()
elif 'darwin' in system:
version, path = get_macos_version()
elif 'linux' in system:
version, path = get_linux_version()
else:
print('UNKNOWN: unsupported platform')
sys.exit(2)
if not version:
print('UNKNOWN: Google Chrome not found or version unreadable')
sys.exit(2)
# Public advisory states patched at 149.0.7827.53 on Linux and 149.0.7827.53/54 on Windows/Mac.
# Treat any version >= 149.0.7827.53 as patched across platforms.
if compare(version, TARGET) >= 0:
print(f'PATCHED: {version[0]}.{version[1]}.{version[2]}.{version[3]} ({path})')
sys.exit(0)
else:
print(f'VULNERABLE: {version[0]}.{version[1]}.{version[2]}.{version[3]} ({path})')
sys.exit(1)
if __name__ == '__main__':
main()
If you remember one thing.
149.0.7827.53, and roll them into your normal browser update motion. Because this reassessment lands at MEDIUM and there is no active exploitation evidence, there is noisgate mitigation SLA — go straight to the 365-day remediation window; under the noisgate remediation SLA, have the actual Chrome update applied within 365 days, though most enterprises should simply let standard browser auto-update rings absorb it well before then.Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.