This is a burglar getting through the lobby turnstile but not the vault door
CVE-2026-10910 is a V8 type confusion bug in Google Chrome that can let a remote attacker run arbitrary code inside Chrome's sandboxed renderer by getting a user to load crafted web content. The affected range is Chrome before 149.0.7827.53; Google's June 2, 2026 stable rollout shipped 149.0.7827.53 for Linux and 149.0.7827.53/.54 for Windows and macOS, with Android inheriting the same desktop security fixes in 149.0.7827.59.
paragraph 2: Google's HIGH 8.8 label is technically fair if you score it as browser RCE from the internet, but it overstates the enterprise patching urgency a bit because the code runs inside the sandbox, there is no KEV listing, the prompt's EPSS is only 0.00081, and I found no public PoC or active exploitation evidence. That said, browsers are one of the few apps every user runs against hostile content all day, so this still lands in defender-priority HIGH, just not at the top of the queue.
4 steps from start to impact.
Deliver malicious web content
- Target uses vulnerable Chrome version
- Victim browses to attacker-controlled or attacker-influenced content
- JavaScript execution is allowed
- Requires user interaction (
UI:R) rather than silent drive-by infrastructure scanning - Email security, web filtering, Safe Browsing, and ad/tracker controls prune a lot of delivery attempts
- Enterprise auto-update sharply reduces the stale-host population
chrome/msedgewebview2 child activity.Trigger the V8 type confusion
- Attacker has a browser-specific exploit for this bug
- Target browser build and platform line up with exploit assumptions
- Mitigations such as exploit hardening do not break reliability
- Browser memory corruption exploits are brittle across versions and architectures
- Chrome's renderer hardening and allocator defenses reduce exploit reliability
- Restricted bug details slow copycat exploitation
Execute inside the renderer sandbox
- Exploit achieves controlled execution
- Renderer sandbox is functioning normally
- Attacker can operate within sandbox restrictions
- Sandboxed execution sharply limits blast radius
- Many post-exploitation actions require a second bug, privileged browser IPC abuse, or social engineering
- EDR still sees browser child-process abuse and LOLBin pivots if a breakout is attempted
Chain to meaningful host impact
- Attacker has a viable post-sandbox chain or can achieve objectives from in-browser context alone
- Target protections do not block follow-on activity
- User/session contains data worth stealing through browser context
- A second exploit or privileged pivot is often required for full endpoint compromise
- MFA, EDR, application control, and browser isolation can stop or contain follow-on steps
- Many enterprises can tolerate a sandboxed renderer compromise better than a native host RCE
The supporting signals.
| In-the-wild status | No confirmed active exploitation found in the consulted source set; not in CISA KEV as of the catalog pages reviewed. |
|---|---|
| Public PoC availability | No public PoC located. The Chromium issue for this bug is present but access-restricted, which is normal during patch rollout and raises copycat friction. |
| EPSS | 0.00081 from the prompt, which is roughly 0.081% modeled 30-day exploit probability; no authoritative percentile was available in the retrieved sources. |
| KEV status | Not KEV-listed; no CISA due date applies. |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H — internet-deliverable with no auth, but user interaction is required and the stated impact is still inside a sandbox. |
| Affected versions | Chrome prior to 149.0.7827.53; Google's desktop stable rollout on 2026-06-02 shipped 149.0.7827.53 (Linux) and 149.0.7827.53/.54 (Windows/Mac). |
| Fixed versions | 149.0.7827.53+ is the safe floor for this CVE; for fleet policy use 149.0.7827.54+ on Windows/macOS if you want the exact desktop stable pair Google rolled out. |
| Disclosure and credit | Published 2026-06-04; Chrome's stable notes credit Mufeed VH from Winfunc Research and show the Chromium bug ID 508811477. |
| Exposure population | This is a browser-client bug, not an internet service. Shodan/Censys/FOFA are basically useless for enumerating exposure; your real inventory source is endpoint software/version telemetry. |
| Detection reality | Best coverage is version inventory + EDR + browser telemetry. Traditional external vuln scanning and perimeter signatures will miss most of the risk. |
noisgate verdict.
The single biggest severity brake is that successful exploitation yields code execution inside Chrome's sandbox, not immediate host-level execution. I kept it in HIGH because attacker position is still just malicious web content to a widely deployed browser, which is a very reachable delivery model across a 10,000-host enterprise.
Why this verdict
- Downgrade from 8.8 because the RCE lands in a sandbox — that is a real containment boundary and it removes the automatic assumption of full host compromise.
- Still HIGH because attacker position is easy — unauthenticated remote delivery through ordinary web content is a reachable path in nearly every enterprise.
- Downward pressure from threat intel — prompt EPSS is 0.00081, KEV is No, and I found no public PoC or public exploitation evidence.
- Upward pressure from exposure — Chrome is ubiquitous, high-frequency, and continuously exposed to untrusted content, so even sandboxed memory corruption deserves fast patching.
- More downward pressure from fleet reality — modern enterprises usually have auto-update, browser isolation, EDR, Safe Browsing, and web filtering that cut exploit reach and post-exploitation payoff.
Why not higher?
There is no evidence here of active exploitation, KEV inclusion, or an available exploit chain that reliably turns renderer execution into host compromise. The need for user interaction plus the sandbox boundary makes this materially less urgent than a browser bug with a published sandbox escape or an already-abused zero-day.
Why not lower?
This is still internet-deliverable memory corruption in the browser engine used by nearly every employee. Even without host escape, a working exploit gives an attacker a foothold in one of the most exposed applications in the fleet, which is too reachable and too common to treat as routine backlog.
What to do — in priority order.
- Enforce Chrome auto-update — Use GPO/MDM/package management to force stable-channel updates and block version pinning. For a HIGH verdict, get this mitigation in place within 30 days if you do not already have it, because stale browsers are the real exposure multiplier.
- Block outdated browser versions — Use EDR, MDM compliance, or NAC to flag and quarantine endpoints running Chrome below 149.0.7827.53. This is the cleanest temporary control for a client-side browser bug and should be deployed within 30 days where feasible.
- Route risky users through browser isolation — Put high-click populations such as finance, exec admins, and helpdesk behind remote/browser isolation for unknown sites. If you cannot patch part of the fleet quickly, apply this compensating control within 30 days to reduce exploit reliability and post-exploitation value.
- Tighten browser child-process policy — Use EDR or application control to block abnormal child processes from Chrome and alert on script interpreters, LOLBins, and credential access spawned by browser processes. This does not stop the renderer bug itself, but it does raise the cost of turning sandboxed execution into real endpoint impact within 30 days.
- Prioritize browser-version inventory — Pull a version census from endpoint management, not from network scanners. For this class of bug, good inventory is the compensating control that tells you whether you actually have a Monday problem or just a patch already rolling.
- A WAF does not help; this is client-side browser exploitation, not a server-side HTTP parsing issue on your edge.
- External vulnerability scanners do not meaningfully enumerate vulnerable Chrome clients, so they will underreport your exposure.
- MFA does not prevent exploitation of the browser engine; it only helps with some follow-on account abuse.
- Generic IDS signatures are weak here because exploit traffic is usually just crafted web content over normal browsing channels.
Crowdsourced verification payload.
Run this on the target endpoint or through your RMM/EDR script runner. Invoke it with python3 check_chrome_cve_2026_10910.py on macOS/Linux or py check_chrome_cve_2026_10910.py on Windows; no admin rights are usually needed, but elevated rights may improve registry and filesystem visibility on locked-down Windows hosts.
#!/usr/bin/env python3
# check_chrome_cve_2026_10910.py
# Detects whether locally installed Google Chrome/Chromium builds are below the fix floor for CVE-2026-10910.
# Outputs exactly one of: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
import os
import platform
import re
import subprocess
import sys
from typing import List, Optional, Tuple
FIXED = (149, 0, 7827, 53)
VERSION_RE = re.compile(r'(\d+)\.(\d+)\.(\d+)\.(\d+)')
def parse_version(text: str) -> Optional[Tuple[int, int, int, int]]:
if not text:
return None
m = VERSION_RE.search(text)
if not m:
return None
return tuple(int(x) for x in m.groups())
def cmp_version(a: Tuple[int, int, int, int], b: Tuple[int, int, int, int]) -> int:
return (a > b) - (a < b)
def run_cmd(cmd: List[str]) -> Optional[str]:
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 None
def windows_versions() -> List[Tuple[str, Tuple[int, int, int, int]]]:
found = []
# Registry query via reg.exe to avoid winreg edge cases in restricted contexts
reg_paths = [
r'HKLM\SOFTWARE\Google\Chrome\BLBeacon',
r'HKLM\SOFTWARE\WOW6432Node\Google\Chrome\BLBeacon',
r'HKCU\SOFTWARE\Google\Chrome\BLBeacon',
r'HKLM\SOFTWARE\Chromium\BLBeacon',
r'HKCU\SOFTWARE\Chromium\BLBeacon',
]
for path in reg_paths:
out = run_cmd(['reg', 'query', path, '/v', 'version'])
if out:
v = parse_version(out)
if v:
found.append((path, v))
exe_paths = [
os.path.join(os.environ.get('ProgramFiles', r'C:\Program Files'), 'Google', 'Chrome', 'Application', 'chrome.exe'),
os.path.join(os.environ.get('ProgramFiles(x86)', r'C:\Program Files (x86)'), 'Google', 'Chrome', 'Application', 'chrome.exe'),
os.path.join(os.environ.get('LocalAppData', ''), 'Google', 'Chrome', 'Application', 'chrome.exe'),
os.path.join(os.environ.get('ProgramFiles', r'C:\Program Files'), 'Chromium', 'Application', 'chrome.exe'),
]
for exe in exe_paths:
if exe and os.path.exists(exe):
out = run_cmd([exe, '--version'])
v = parse_version(out or '')
if v:
found.append((exe, v))
return dedupe(found)
def mac_versions() -> List[Tuple[str, Tuple[int, int, int, int]]]:
found = []
paths = [
'/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
'/Applications/Chromium.app/Contents/MacOS/Chromium',
os.path.expanduser('~/Applications/Chromium.app/Contents/MacOS/Chromium'),
]
for p in paths:
if os.path.exists(p):
out = run_cmd([p, '--version'])
v = parse_version(out or '')
if v:
found.append((p, v))
return dedupe(found)
def linux_versions() -> List[Tuple[str, Tuple[int, int, int, int]]]:
found = []
cmds = [
['google-chrome', '--version'],
['google-chrome-stable', '--version'],
['chromium', '--version'],
['chromium-browser', '--version'],
]
for cmd in cmds:
out = run_cmd(cmd)
v = parse_version(out or '')
if v:
found.append((' '.join(cmd), v))
return dedupe(found)
def dedupe(items: List[Tuple[str, Tuple[int, int, int, int]]]) -> List[Tuple[str, Tuple[int, int, int, int]]]:
seen = set()
result = []
for src, ver in items:
key = (src, ver)
if key not in seen:
seen.add(key)
result.append((src, ver))
return result
def main() -> int:
system = platform.system().lower()
versions: List[Tuple[str, Tuple[int, int, int, int]]] = []
if 'windows' in system:
versions = windows_versions()
elif 'darwin' in system:
versions = mac_versions()
elif 'linux' in system:
versions = linux_versions()
else:
print('UNKNOWN')
return 2
if not versions:
print('UNKNOWN')
return 2
vulnerable = []
patched = []
for src, ver in versions:
if cmp_version(ver, FIXED) < 0:
vulnerable.append((src, ver))
else:
patched.append((src, ver))
if vulnerable:
print('VULNERABLE')
return 1
if patched:
print('PATCHED')
return 0
print('UNKNOWN')
return 2
if __name__ == '__main__':
sys.exit(main())
If you remember one thing.
Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.