This is a loaded trapdoor on a public sidewalk, but the victim still has to step on the marked tile
This Chrome bug is described as a use-after-free in V8 affecting Google Chrome before 149.0.7827.53 on Linux and before 149.0.7827.53/.54 on Windows and macOS. In plain English: a malicious page can try to corrupt memory in the JavaScript engine, but the attacker reportedly needs the user to perform a specific UI gesture, not just passively render a page.
The vendor's 8.8/HIGH baseline is directionally fair for a browser memory-corruption issue in a massively deployed product, but it slightly overstates real enterprise risk. The attack is still remote and pre-auth, which matters, yet the chain has two big brakes: user interaction beyond a normal click/view and Chrome's renderer sandbox, which usually turns a single browser bug into code execution in a constrained process rather than instant host takeover.
4 steps from start to impact.
Deliver a malicious web page
- Target uses Chrome in the affected version range
- Attacker can get the victim to a malicious or attacker-controlled page
- JavaScript is allowed to run
- Enterprise email/web filtering regularly strips or blocks commodity delivery paths
- Adversary still needs a user-targeting channel; this is not internet-scan-and-pop
Induce the required UI gesture
- Victim completes the needed gesture
- The site can present believable lure content long enough to trigger it
- This requirement sharply reduces opportunistic exploitation volume
- Modern browser warnings, user training, and page-isolation tooling break many lure flows
Trigger V8 memory corruption
- Exploit primitives line up on the target build
- The target platform's mitigations do not stop reliability
- Chrome exploit reliability varies by OS build, allocator behavior, and mitigation state
- No confirmed in-the-wild exploitation or KEV entry reduces urgency versus a proven zero-day
Operate within the browser sandbox
- Exploit succeeds in the renderer
- Desired objective is achievable from browser context or attacker has a second-stage escape
- Chrome's sandbox limits direct blast radius from a single bug
- A second vulnerability is often required for durable OS-level compromise
The supporting signals.
| In-the-wild status | No confirmed active exploitation found in the sourced material, and not listed in CISA KEV. |
|---|---|
| Proof-of-concept availability | No public working PoC located in the sources. That lowers immediate copycat risk, though V8 memory bugs are a familiar exploit target for capable actors. |
| EPSS | 0.0008 from the user-provided intel, which is very low and consistent with a fresh browser client bug that lacks public exploitation evidence. |
| KEV status | Not KEV-listed as of this assessment; no CISA date-added entry found. |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H — remote and no privileges required, but user interaction is mandatory, which is the key real-world brake. |
| Affected versions | Google Chrome prior to 149.0.7827.53; desktop release notes indicate 149.0.7827.53 (Linux) and 149.0.7827.53/.54 (Windows/Mac) as the fixed train. |
| Fixed versions | Patch to 149.0.7827.53 or later on Linux and 149.0.7827.54 or later on Windows/macOS where that build is the shipped stable release. Chrome's rapid channel cadence means later 149+ builds also contain the fix. |
| Exposure reality | This is not internet-scannable like a VPN or appliance bug; Shodan/Censys-style exposure counts are mostly irrelevant. The exposure population is your installed Chrome estate, which is usually enormous in enterprise. |
| Disclosure date | 2026-06-04 per the user-provided intel; the Chrome stable desktop security release was published 2026-06-02 and national advisory follow-on appeared 2026-06-03. |
| Researcher / reporting | The exact researcher attribution for CVE-2026-10991 was not clearly exposed in the public official release excerpt reviewed. Google commonly withholds detailed bug metadata until patch adoption improves. |
noisgate verdict.
The decisive factor is the required specific UI gesture, which pushes this out of pure drive-by territory and cuts down the population that can be exploited at scale. It stays HIGH because Chrome is ubiquitous, the bug is still pre-auth remote against end users, and a renderer compromise is still a serious foothold for session theft and follow-on tradecraft.
Why this verdict
- Down from 8.8 because UI:R is not cosmetic here — the description says a *specific UI gesture* is needed, which adds social-engineering and reliability friction beyond 'visit page, get popped.'
- Still HIGH because attacker position is only remote web access — no authentication, no internal foothold, no prior compromise, and the target population is basically every Chrome user in your fleet.
- Down again because blast radius starts in the browser sandbox — absent evidence of a paired sandbox escape or zero-day chaining, this is usually a constrained renderer win first, not instant domain compromise.
Why not higher?
There is no KEV listing, no sourced active exploitation evidence, and no public PoC in the material reviewed. More importantly, the chain requires victim interaction and likely yields a sandboxed browser foothold first, which is serious but not the same as a one-packet perimeter RCE.
Why not lower?
This is still a remote memory-corruption flaw in Chrome's JavaScript engine, not a niche admin-only bug. Chrome's deployment scale means even moderate exploit friction can still translate into meaningful enterprise exposure, especially for high-value users who browse untrusted content.
What to do — in priority order.
- Force browser auto-update compliance — Use Chrome enterprise policy or your endpoint management stack to verify the fleet is moving to 149.0.7827.53/54+. For a HIGH verdict, deploy and validate this within 30 days, because the fastest risk reduction here is simply shrinking the affected browser population.
- Tighten risky site access — Use secure web gateway controls, category blocks, and link isolation for unknown domains, newly registered sites, and ad-heavy destinations. This helps break step 1 of the chain and should be in place or tuned within 30 days.
- Isolate high-risk browsing roles — Put executives, finance, admins, developers, and help desk into browser isolation or hardened browsing profiles first. That limits impact if an exploit lands and should be prioritized within 30 days for the highest-value users.
- Watch for Chrome crash and spawn anomalies — Alert on spikes in
chrome/google-chromecrashes, browser child-process launches, and suspicious downloads immediately after browsing events. This will not prevent exploitation, but it improves containment of successful attempts and should be tuned within 30 days.
MFAdoes not stop initial browser exploitation; it only helps after credential theft or session abuse.Perimeter vulnerability scanningwill not find this reliably because it is an endpoint client-version problem, not an exposed listening service.WAF rulesare mostly irrelevant unless you fully control the malicious site, which you do not in the normal phishing or malvertising case.
Crowdsourced verification payload.
Run this on the target endpoint or through your software inventory/EDR remote execution feature. Invoke it as python3 check_chrome_cve_2026_10991.py on macOS/Linux or py check_chrome_cve_2026_10991.py on Windows; it needs standard user rights only and reports VULNERABLE, PATCHED, or UNKNOWN based on the locally installed Chrome version.
#!/usr/bin/env python3
# check_chrome_cve_2026_10991.py
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
import os
import platform
import re
import subprocess
import sys
FIXED = (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_windows():
try:
import winreg
except Exception:
return 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:
with winreg.OpenKey(hive, path) as key:
value, _ = winreg.QueryValueEx(key, name)
v = parse_version(str(value))
if v:
return v
except OSError:
pass
return None
def run_cmd(cmd):
try:
p = subprocess.run(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True, timeout=10)
out = (p.stdout or '') + ' ' + (p.stderr or '')
return parse_version(out)
except Exception:
return None
def get_version_macos():
plist_path = '/Applications/Google Chrome.app/Contents/Info.plist'
if os.path.exists(plist_path):
v = run_cmd(['/usr/bin/defaults', 'read', plist_path, 'CFBundleShortVersionString'])
if v:
return v
return run_cmd(['/Applications/Google Chrome.app/Contents/MacOS/Google Chrome', '--version'])
def get_version_linux():
candidates = [
['google-chrome', '--version'],
['google-chrome-stable', '--version'],
['chromium-browser', '--version'],
['chromium', '--version'],
]
for cmd in candidates:
v = run_cmd(cmd)
if v:
return v
return None
def main():
system = platform.system().lower()
if 'windows' in system:
version = get_version_windows()
elif 'darwin' in system:
version = get_version_macos()
elif 'linux' in system:
version = get_version_linux()
else:
print('UNKNOWN: unsupported platform')
sys.exit(2)
if not version:
print('UNKNOWN: could not determine installed Chrome version')
sys.exit(2)
print('Detected Chrome version: %s' % '.'.join(map(str, version)))
if cmp_ver(version, FIXED) < 0:
print('VULNERABLE')
sys.exit(1)
else:
print('PATCHED')
sys.exit(0)
if __name__ == '__main__':
main()
If you remember one thing.
Sources
- Chrome Releases - Stable Channel Update for Desktop (Chrome 149.0.7827.53/.54)
- Chrome Releases main feed showing Chrome 149 stable rollout
- Canadian Centre for Cyber Security - Google Chrome security advisory AV26-544
- CISA Known Exploited Vulnerabilities Catalog
- FIRST EPSS overview
- MITRE CWE-416 Use After Free
- VulDB aggregated listing for CVE-2026-10991
- InfoProtección aggregated Chrome CVE listing including CVE-2026-10991
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.