This is a bad lock on an interior door, not an open front gate
CVE-2026-10995 is a heap buffer overflow in Chrome's TabStrip UI component affecting Google Chrome versions earlier than 149.0.7827.53. The bug is triggered from a crafted HTML page, but the attacker also has to get the victim to perform *specific UI gestures* while interacting with the browser. That is materially different from the classic no-click renderer bug: this sits in a UI path, not a broadly reachable network service, and its preconditions narrow the real-world hit rate.
The supplied 8.8/HIGH baseline overstates operational risk for enterprise patch triage. Google's own June 2, 2026 stable release groups CVE-2026-10995 as Medium, and that tracks reality better: there is no KEV listing, EPSS is extremely low, no public exploit chain is visible, and the attack needs both page delivery and human choreography. Still, it is a memory corruption bug in the most widely deployed browser on most fleets, so this is not backlog trash.
4 steps from start to impact.
Deliver a lure page
TabStrip code path. In practice this means a phishing link, malvertising redirect, or compromised site rather than a blind network probe. There is no internet-exposed daemon here; reachability is entirely mediated by user browsing.- Target is running Google Chrome earlier than
149.0.7827.53 - Victim can be induced to open attacker-controlled web content
- Chrome is allowed for general web access on the endpoint
- Email security, SWG, DNS filtering, and Safe Browsing can block the lure before the browser ever sees it
- This is a client-side browser flaw, so mass scanner discovery is not practical
Force exact UI interaction
- Victim performs the required UI gestures in the attacker-chosen sequence
- The browser window and tab state line up with the exploit assumptions
- Users do not naturally reproduce precise gesture chains at scale
- Security awareness, browser isolation, and user friction reduce completion rates
- UI-path bugs are often timing-sensitive and brittle across platforms and window states
Corrupt heap state in the browser
TabStrip overflow. That can yield a crash, info leak, or controlled memory primitive depending on allocator state and exploit quality. No public weaponized exploit is visible, so assume reliability is non-trivial rather than turnkey.- Memory layout is favorable on the target platform
- The crafted content successfully grooms heap state
- Modern Chrome mitigations, allocator randomness, and exploit hardening reduce reliability
- A memory corruption primitive in a UI component is usually harder to stabilize than a simple logic flaw
chrome crashes around the same URL or campaign.Convert browser corruption into useful impact
- Attacker turns corruption into a stable primitive
- Any desired post-browser objective is reachable without an additional escape
- Sandbox boundaries may limit direct host impact
- Most serious host takeover outcomes would require a second vulnerability or weak local controls
chrome process behavior, shellcode-like memory patterns, or unexpected child process/network activity. Absent that, defenders mainly see crashes or nothing.The supporting signals.
| In-the-wild status | No current exploitation evidence located. Not in CISA KEV and no public campaign reporting found in the reviewed sources. See CISA KEV catalog and OpenCVE. |
|---|---|
| Proof-of-concept availability | No public PoC seen. The Chromium issue exists at 505371980 but is restricted, and no public exploit references appeared in the vendor release or reviewed sources. |
| EPSS | 0.00032 per the CVE metadata surfaced by OpenCVE, which is effectively noise-floor threat probability. |
| KEV status | Not listed in CISA's Known Exploited Vulnerabilities Catalog as of the CVE's June 2026 disclosure. |
| CVSS / severity mismatch | Important mismatch: your supplied baseline is 8.8/HIGH, but Google's June 2, 2026 release note lists CVE-2026-10995 as Medium in the 149 stable train: Chrome stable 149 release. |
| Affected versions | Google Chrome < 149.0.7827.53 on desktop platforms. OpenCVE shows the affected range as 0,149.0.7827.53): [OpenCVE record. |
| Fixed version | Patched in 149.0.7827.53 for Linux and 149.0.7827.53/54 for Windows/Mac per the Chrome 149 stable release. |
| Exposure reality | Huge installed base, poor external measurability. Chrome still dominates browser usage globally, around 70.25% overall in StatCounter's May 2026 data, but internet scanners cannot directly enumerate vulnerable browser clients: StatCounter. |
| Disclosure / reporting | Disclosed 2026-06-04; reported by Sven Dysthe (@svn-dys) on 2026-04-22 per OpenCVE and the Chrome stable release note. |
| Why it is not higher | Two compounding brakes: UI:R is already a reduction, and '*specific UI gestures*' is a second, stronger reduction because it implies a brittle, socially engineered exploit path instead of simple page-load reachability. |
noisgate verdict.
The decisive factor is the specific UI gesture requirement. That prerequisite turns a theoretically nasty memory corruption bug into a far narrower, low-reliability, post-click attack path with no observed exploitation signal behind it today.
Why this verdict
- Down from 8.8 because this is not a no-click browser bug — the victim must browse attacker content *and* perform specific UI gestures, which is more restrictive than ordinary
UI:Rweb exploitation. - Down again because the attacker position is still pre-compromise internet delivery, but the reachable population for the vulnerable code path is narrower than Chrome's raw install base; many users will see the page, few will reproduce the exact gesture chain.
- Down again because there is no exploitation signal — no KEV listing, very low EPSS (
0.00032), and no public PoC or campaign reporting in the reviewed sources. - Kept at MEDIUM instead of LOW because Chrome is everywhere and heap corruption bugs can still become valuable when paired with social engineering or a second-stage escape.
Why not higher?
A higher rating would fit a renderer bug with page-load-only reachability, a public exploit, or active exploitation. We do not have any of those here. The required UI choreography and likely exploit brittleness are real-world friction points that sharply reduce both attacker success rate and enterprise-wide urgency.
Why not lower?
This is still memory corruption in the dominant browser on enterprise endpoints, not a cosmetic UI issue. If the gesture chain is met, the bug plausibly enables meaningful browser-process compromise, so dismissing it as hygiene would be too optimistic. Chrome's prevalence keeps the population size large even when exploitability is constrained.
What to do — in priority order.
- Enforce browser version compliance — Use MDM, EDR, or software inventory to flag any host running Chrome
< 149.0.7827.53and block drift from auto-update rings. Because this is MEDIUM, there is no mitigation SLA — go straight to the 365-day remediation window, but mature shops should close browser lag much sooner as normal endpoint hygiene. - Keep Safe Browsing and web filtering on — This bug still needs malicious content delivery, so URL filtering, DNS controls, SWG, and Chrome Safe Browsing reduce attacker access to the trigger page. For this verdict there is no mitigation SLA, so treat this as standing control hardening while you complete remediation inside the 365-day window.
- Isolate high-risk browsing roles — Apply browser isolation or hardened browsing profiles for executives, admins, help desk, finance, and users who live in webmail or unknown links. That does not eliminate the bug, but it materially lowers the chance that precise gesture-based exploitation succeeds before remediation.
- Watch for Chrome crash clusters — Pull browser crash telemetry and EDR fault events for repeated
chromecrashes after2026-06-04, especially around phishing campaigns or uncommon domains. Repeated tab/UI crashes can be your only early hint that someone is trying to exercise this path.
- A perimeter vulnerability scan won't tell you much beyond browser version presence; this is a client-side flaw, not an exposed TCP service.
- Firewall rules do not meaningfully mitigate a browser bug delivered over ordinary web traffic users already need.
- MFA is good security, but it does not stop the memory corruption step; it only helps if the attacker later pivots into account abuse.
Crowdsourced verification payload.
Run this on the target endpoint or through your fleet-management agent. Invoke it with python3 chrome_cve_2026_10995_check.py on macOS/Linux or py chrome_cve_2026_10995_check.py on Windows; no admin rights are required if the script can read the Chrome executable version metadata from standard install paths.
#!/usr/bin/env python3
# CVE-2026-10995 Google Chrome version check
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
import os
import platform
import re
import subprocess
import sys
from shutil import which
TARGET = (149, 0, 7827, 53)
def parse_version(text):
if not text:
return None
m = re.search(r'(\d+)\.(\d+)\.(\d+)\.(\d+)', text)
if not m:
return None
return tuple(int(x) for x in m.groups())
def cmp_ver(a, b):
return (a > b) - (a < b)
def get_version_from_command(cmd):
try:
out = subprocess.check_output(cmd, stderr=subprocess.STDOUT, text=True, timeout=10)
return parse_version(out.strip())
except Exception:
return None
def get_linux_version():
candidates = [
["google-chrome", "--version"],
["google-chrome-stable", "--version"],
["/opt/google/chrome/chrome", "--version"],
["chromium", "--version"],
["chromium-browser", "--version"],
]
for cmd in candidates:
exe = cmd[0]
if exe.startswith("/") or which(exe):
v = get_version_from_command(cmd)
if v:
return v, " ".join(cmd)
return None, None
def get_macos_version():
candidates = [
"/Applications/Google Chrome.app/Contents/MacOS/Google Chrome",
os.path.expanduser("~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome"),
]
for app in candidates:
if os.path.exists(app):
v = get_version_from_command([app, "--version"])
if v:
return v, app
return None, None
def get_windows_version():
try:
import winreg
except Exception:
winreg = None
# Try registry first
if winreg is not None:
reg_paths = [
(winreg.HKEY_CURRENT_USER, r"Software\Google\Chrome\BLBeacon", "version"),
(winreg.HKEY_LOCAL_MACHINE, r"Software\Google\Chrome\BLBeacon", "version"),
(winreg.HKEY_LOCAL_MACHINE, r"Software\WOW6432Node\Google\Chrome\BLBeacon", "version"),
]
for hive, path, name in reg_paths:
try:
key = winreg.OpenKey(hive, path)
value, _ = winreg.QueryValueEx(key, name)
v = parse_version(str(value))
if v:
return v, f"registry:{path}"
except Exception:
pass
# Fallback to executable version via PowerShell
candidates = [
os.path.join(os.environ.get("ProgramFiles", r"C:\Program Files"), r"Google\Chrome\Application\chrome.exe"),
os.path.join(os.environ.get("ProgramFiles(x86)", r"C:\Program Files (x86)"), r"Google\Chrome\Application\chrome.exe"),
os.path.join(os.environ.get("LOCALAPPDATA", ""), r"Google\Chrome\Application\chrome.exe"),
]
for exe in candidates:
if exe and os.path.exists(exe):
ps = [
"powershell",
"-NoProfile",
"-Command",
f"(Get-Item '{exe}').VersionInfo.ProductVersion"
]
v = get_version_from_command(ps)
if v:
return v, exe
return None, None
def main():
system = platform.system().lower()
if system == "windows":
version, source = get_windows_version()
elif system == "darwin":
version, source = get_macos_version()
else:
version, source = get_linux_version()
if not version:
print("UNKNOWN - Google Chrome version not found")
sys.exit(2)
if cmp_ver(version, TARGET) < 0:
print(f"VULNERABLE - found {'.'.join(map(str, version))} via {source}; need >= {'.'.join(map(str, TARGET))}")
sys.exit(1)
else:
print(f"PATCHED - found {'.'.join(map(str, version))} via {source}; fixed version is >= {'.'.join(map(str, TARGET))}")
sys.exit(0)
if __name__ == "__main__":
main()
If you remember one thing.
Chrome < 149.0.7827.53, and keep your normal web controls in place; for a MEDIUM finding there is noisgate mitigation SLA — no mitigation SLA — go straight to the 365-day remediation window. Your noisgate remediation SLA is ≤365 days, but because this is a browser and the patch already exists, most enterprises should simply let normal browser update rings clear it well before that outer limit and confirm stragglers in unmanaged or kiosk populations.Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.