This is a burglar who can get into the lobby fast, but still needs another key to reach the server room
CVE-2026-10936 is a V8 type confusion bug in Google Chrome that can be triggered by an attacker-controlled HTML page, leading to arbitrary code execution inside the Chrome sandbox. Based on the vendor intel provided and Google's release notes, affected versions are Chrome prior to 149.0.7827.53 on Linux and prior to 149.0.7827.53/.54 on Windows and macOS.
Google's HIGH 8.8 baseline is directionally fair because Chrome is everywhere and the delivery vector is just web content. But in real enterprise conditions this is not the same as unauthenticated host compromise: the attacker still needs the user to hit malicious content, then still lands in a renderer sandbox, and needs a second bug or a very specific browser-resident objective to turn this into full workstation impact.
4 steps from start to impact.
Deliver a crafted page
- Target is running vulnerable Chrome before 149.0.7827.53
- User browses to attacker-controlled content
- JavaScript execution is allowed
- Enterprise DNS filtering, SWG, browser isolation, and email controls cut down first-touch delivery
- This is UI:R; the victim has to render the page, so it is not wormable
Trigger V8 type confusion
- Exploit logic matches the victim's exact V8 build behavior
- Memory corruption is reachable from the crafted page
- Modern Chrome exploit mitigations, JIT variability, and hardening make reliability non-trivial
- Public bug details appear restricted pending patch adoption, which raises attacker development cost
Get code execution in the renderer sandbox
- Exploit achieves stable code execution rather than a crash
- Renderer sandbox remains the landing context
- The sandbox sharply limits filesystem, process, and device access
- Many enterprise EDR controls will flag suspicious child-process or broker abuse if the attacker tries to break out
Chain to real workstation impact
- A separate sandbox escape or local privilege escalation exists
- Or the attacker only needs in-browser actions/data from the current session
- No KEV listing, no active exploitation evidence, and no public chain were identified
- Without a second bug, blast radius is usually limited to the browser context and current user activity
The supporting signals.
| In-the-wild status | No current public evidence of in-the-wild exploitation found in reviewed sources. Not listed in CISA KEV, and the Chrome release material reviewed did not claim active exploitation. |
|---|---|
| Public PoC | No public PoC identified in primary-source review at write time. This is partly expected: Chrome often keeps bug details restricted until most users are patched. |
| EPSS | 0.00081 from the user-supplied intel block; percentile not independently verified from a primary EPSS record during this review. |
| KEV status | Not KEV-listed; therefore there is no CISA due date. |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H = drive-by capable, no auth required, but user interaction is required and the stated impact is still bounded by Chrome's sandbox in the base flaw. |
| Affected versions | Chrome before 149.0.7827.53 on Linux and before 149.0.7827.53/.54 on Windows/macOS, per Google's release note and the Canadian Cyber Centre advisory. |
| Fixed versions | Patched in 149.0.7827.53 (Linux) and 149.0.7827.53/.54 (Windows/macOS). For fleet triage, treat 149.0.7827.53 or newer as the minimum safe floor unless your platform build explicitly tracks .54. |
| Exposure reality | This is widely deployed endpoint software, so the reachable population is large. But it is not meaningfully internet-scannable like a server CVE; Shodan/Censys-style exposure counts are the wrong lens here. |
| Disclosure | Disclosed 2026-06-04 from the user-provided intel. Google had already pushed the relevant 149.0.7827.53/.54 early stable update on 2026-05-29. |
| Researcher / reporter | Not publicly named in the reviewed sources. That is common for Chrome issues while bug details remain restricted. |
noisgate verdict.
The decisive factor is that the bug lands the attacker inside Chrome's sandbox, not on the host. That keeps this in HIGH rather than CRITICAL, even though Chrome is ubiquitous and the delivery mechanism is just a malicious web page.
Why this verdict
- Downgrade for sandbox boundary: the CVE gives renderer-level code execution, but real workstation compromise usually needs a second vulnerability or a browser-resident objective.
- Keep it elevated for reach: Chrome is ubiquitous in enterprise fleets, the attack is remote, and delivery is ordinary web content rather than a niche local condition.
- Downgrade for threat evidence: no KEV listing, no public PoC found in primary-source review, and the supplied EPSS is very low, which argues against emergency treatment.
Why not higher?
This is not a straight line to host takeover. The attacker needs the user to render malicious content and then still hits Chrome's sandbox, which is a real containment boundary in modern enterprise builds. Without a public exploit chain or active exploitation evidence, calling this CRITICAL would overstate the likely Monday-morning risk.
Why not lower?
Do not talk yourself into backlog status just because it is sandboxed. This is still remote, web-deliverable memory corruption in one of the most exposed applications in the fleet, and successful exploitation can still enable session abuse, in-browser actions, and fast chaining if a second bug exists.
What to do — in priority order.
- Force managed browser updates — Push Chrome to 149.0.7827.53 or newer and require relaunch on lagging endpoints. For a HIGH verdict, deploy this compensating action within 30 days, but in practice browsers are one of the few areas where you should finish far faster.
- Gate access from outdated browsers — Use conditional access, proxy policy, or VDI/browser management to block sensitive SaaS access from Chrome builds below the fixed floor. This reduces the value of a renderer exploit while patch rollout catches up; deploy within 30 days.
- Route risky browsing through isolation — Send uncategorized, newly registered, and high-risk destinations through remote browser isolation or equivalent SWG controls. This does not remove the bug, but it lowers the chance that vulnerable endpoints render attacker-controlled exploit pages; deploy within 30 days.
- Hunt for abnormal browser follow-on activity — Tune EDR and SIEM for browser child-process creation, unexpected broker access, and spikes in Chrome crash telemetry. This is your backstop if someone tries to turn a renderer compromise into a host event; deploy within 30 days.
- External vulnerability scanning does not help much here because this is client software, not an exposed service.
- MFA alone does not stop a browser memory-corruption exploit; it only helps on specific post-exploitation account abuse paths.
- WAF rules are largely irrelevant unless you control the malicious content origin, because the delivery path is the user's browser rendering hostile web content.
Crowdsourced verification payload.
Run this on the target endpoint or via your endpoint-management tooling. Invoke it as python3 check_cve_2026_10936.py on macOS/Linux or py check_cve_2026_10936.py on Windows; standard user rights are usually enough because it only reads local application version data.
#!/usr/bin/env python3
# check_cve_2026_10936.py
# Determine whether the local Google Chrome / Chromium installation is vulnerable to CVE-2026-10936.
# Outputs one of: VULNERABLE, PATCHED, UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
import os
import platform
import re
import shutil
import subprocess
import sys
from pathlib import Path
FIXED_MIN = (149, 0, 7827, 53)
CANDIDATES = {
'Windows': [
r'C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe',
r'C:\\Program Files (x86)\\Google\\Chrome\\Application\\chrome.exe',
r'C:\\Program Files\\Chromium\\Application\\chrome.exe',
r'C:\\Program Files (x86)\\Chromium\\Application\\chrome.exe',
],
'Darwin': [
'/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
'/Applications/Chromium.app/Contents/MacOS/Chromium',
],
'Linux': [
'google-chrome',
'google-chrome-stable',
'chromium',
'chromium-browser',
'/opt/google/chrome/chrome',
'/usr/bin/google-chrome',
'/usr/bin/google-chrome-stable',
'/usr/bin/chromium',
'/usr/bin/chromium-browser',
]
}
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 version_str(v):
return '.'.join(str(x) for x in v)
def is_patched(v):
return v >= FIXED_MIN
def get_version_from_binary(path):
try:
completed = subprocess.run([path, '--version'], capture_output=True, text=True, timeout=10)
output = (completed.stdout or '') + ' ' + (completed.stderr or '')
return parse_version(output)
except Exception:
return None
def find_existing_paths():
system = platform.system()
candidates = CANDIDATES.get(system, [])
resolved = []
for c in candidates:
if os.path.isabs(c):
if Path(c).exists():
resolved.append(c)
else:
found = shutil.which(c)
if found:
resolved.append(found)
# de-duplicate while preserving order
seen = set()
unique = []
for p in resolved:
if p not in seen:
seen.add(p)
unique.append(p)
return unique
def main():
paths = find_existing_paths()
findings = []
for p in paths:
ver = get_version_from_binary(p)
if ver:
findings.append((p, ver))
if not findings:
print('UNKNOWN - Chrome/Chromium binary not found or version unreadable')
sys.exit(2)
# choose the highest discovered version if multiple are present
findings.sort(key=lambda x: x[1], reverse=True)
path, ver = findings[0]
if is_patched(ver):
print(f'PATCHED - found {path} version {version_str(ver)} (fixed floor: {version_str(FIXED_MIN)})')
sys.exit(0)
else:
print(f'VULNERABLE - found {path} version {version_str(ver)} (fixed floor: {version_str(FIXED_MIN)})')
sys.exit(1)
if __name__ == '__main__':
main()
If you remember one thing.
Sources
- Google Chrome Releases - Early Stable Update for Desktop (May 29, 2026)
- Google Chrome Releases main page
- Canadian Centre for Cyber Security advisory AV26-544
- CISA Known Exploited Vulnerabilities Catalog
- FIRST EPSS data and stats
- FIRST EPSS API documentation
- CVEProject cvelistV5 repository
- Quanteta CVE tracker entry showing CVE-2026-10936 metadata
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.