This is a guardrail with a gap in it, not a missing wall
CVE-2026-11210 is a Safe Browsing policy/access-control bypass in desktop Google Chrome. Per Google/NVD, affected builds are Chrome before 149.0.7827.53; the fixed builds are 149.0.7827.53 on Linux and 149.0.7827.53/.54 on Windows and macOS. The published trigger is a crafted RAR file, so this is not a generic web-page memory corruption bug; the attacker needs the victim to encounter a specific archive-handling path.
The vendor's MEDIUM 6.5 is technically defensible in CVSS terms, but it overstates enterprise urgency. In the real world this is a user-driven, client-side, defense-in-depth bypass with no public sign of in-the-wild exploitation, no public PoC located, and no disclosed path to full code execution by itself. For a team managing 10,000 hosts, this belongs in backlog hygiene, not the emergency lane.
4 steps from start to impact.
Land the archive
- Attacker can reach a user by email, chat, ad, or web lure
- Target uses desktop Chrome below 149.0.7827.53
- Target is willing to download or interact with the archive
- Secure email gateways often quarantine or strip RAR attachments
- Web proxies and browser isolation reduce archive delivery success
- User interaction is mandatory, which kills mass reliability
Trigger the Safe Browsing bypass
- Victim receives the crafted archive through Chrome's download flow
- The relevant Safe Browsing decision path is reached
- Bug details remain restricted in Chromium's tracker, limiting attacker reproducibility
- Archive inspection, content disarm, and endpoint AV reduce success
Abuse the bypassed control
- The bypass must actually weaken a meaningful enterprise policy or trust decision
- The user or a follow-on process must act on the delivered content
- The CVE does not disclose a direct RCE or sandbox-escape outcome
- EDR, Mark-of-the-Web handling, application control, and attachment detonation still sit downstream
Impact stays in the user lane
- A second failure or unsafe user action is needed for bigger impact
- No active exploitation evidence in the cited sources
- No public chain to system compromise is disclosed
The supporting signals.
| In-the-wild status | No current exploitation evidence in the cited primary sources. Not in CISA KEV, and Google did not flag it as exploited. |
|---|---|
| Proof-of-concept availability | No public PoC located in the reviewed primary sources/searches. Chromium bug details are still restricted, which raises attacker friction. |
| EPSS | 0.0002 from the prompt, which is effectively negligible as a 30-day exploitation signal. Percentile was not supplied in the prompt and not verified from a primary EPSS response. |
| KEV status | Not KEV-listed. CISA's catalog page does not list CVE-2026-11210; there is therefore no KEV date-added or due date. |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N = remote delivery is possible, but user interaction is required and the disclosed impact is integrity-only, not confidentiality loss or availability hit. |
| Affected versions | Desktop Chrome before 149.0.7827.53. NVD's CPE mapping ties this to Windows, Linux, and macOS desktop Chrome. |
| Fixed versions | Linux: 149.0.7827.53. Windows/macOS: 149.0.7827.53/.54 per Google's stable release post. |
| Scanning / exposure reality | Shodan/Censys/FOFA-style internet exposure metrics are basically irrelevant here because this is endpoint browser software, not an internet-facing service. GreyNoise-style scanner activity is also a poor fit for a client-side archive-triggered bug. |
| Disclosure timeline | Reported by Google on 2026-04-25 in the Chrome release notes; publicly disclosed 2026-06-04 in the CVE/NVD records; NVD added CPEs on 2026-06-05. |
| Researcher / reporter | Google is the named reporter in the Chrome stable channel advisory entry for this CVE. No external researcher attribution is published in the visible advisory text. |
noisgate verdict.
The deciding factor is that this is a client-side control bypass that still needs user interaction with a crafted RAR, not a no-click browser compromise. Chrome is everywhere, but the reachable exploit path is narrow and the publicly disclosed impact does not show a direct route to code execution or tenant-wide blast radius.
Why this verdict
- User interaction cuts this down: the attacker needs a victim to receive and engage with a crafted RAR, which implies phishing or a download lure rather than blind internet exploitation.
- Archive-specific delivery narrows the population: many enterprises block, detonate, or heavily inspect RAR files at mail gateways, proxies, and endpoints.
- This is a defense-in-depth bypass, not a published RCE: the disclosed outcome is access-control/policy bypass with integrity impact, not arbitrary code execution, sandbox escape, or credential theft by itself.
- Threat intel is quiet: no KEV listing, no public exploitation callout from Google, and the provided EPSS 0.0002 says attackers are not obviously prioritizing this.
- Chrome ubiquity stops this from being IGNORE: the browser footprint is huge, and weakening Safe Browsing on thousands of endpoints is still worth closing during normal hygiene.
Why not higher?
To rate higher, I would need either active exploitation, public exploit tooling, or a disclosed path to reliable code execution / sandbox escape / credential theft. None of that is in the primary sources. The attacker also has to clear too many ordinary enterprise controls first: delivery, user action, archive handling, and downstream endpoint controls.
Why not lower?
I am not calling this IGNORE because Chrome is a massively deployed endpoint platform and Safe Browsing exists in a very attacker-relevant part of the chain: getting bad content onto user systems. Even a control bypass with modest standalone impact can become useful when chained with weak archive handling, poor application control, or a second-stage social-engineering payload.
What to do — in priority order.
- Block or detonate RAR at the edge — If your mail gateway, SWG, or sandbox supports archive policy, block or detonate RAR downloads and attachments for standard users. For a LOW verdict there is no SLA (treat as backlog hygiene), so fold this into normal policy tuning rather than emergency change windows.
- Enforce Chrome evergreen updates — Make sure enterprise policy is not pinning outdated Chrome builds and that update rings actually move endpoints to 149.0.7827.53+. For LOW, there is no SLA (treat as backlog hygiene); this should ride your standard browser maintenance cycle.
- Tighten archive execution controls — Use EDR, application control, ASR, Gatekeeper, or equivalent controls to stop downloaded archive contents from launching freely in user context. That matters because this CVE is most useful to attackers when it can be chained with unsafe post-download execution behavior.
- Monitor download-and-extract chains — Alert on Chrome-originated RAR downloads followed by extraction and child-process launches from temp/download locations. This is the best operational signal because the CVE itself is hard to observe directly.
- A WAF does not help; this is not a server-side web app exposure.
- Perimeter network vulnerability scanning does not meaningfully validate exploitability here; it can only inventory browser versions if you have agent or authenticated host access.
- Relying on Safe Browsing alone is the wrong lesson; this bug is specifically about a Safe Browsing enforcement gap.
Crowdsourced verification payload.
Run this on the target endpoint or through your EDR/RMM script runner; it needs only standard user privileges because it reads local app metadata. Save it as check_cve_2026_11210.py and run python3 check_cve_2026_11210.py on Linux/macOS or py check_cve_2026_11210.py on Windows; it will print VULNERABLE, PATCHED, or UNKNOWN and exit with 1, 0, or 2 respectively.
#!/usr/bin/env python3
# Check Google Chrome version for CVE-2026-11210
# 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(s):
m = re.search(r'(\d+)\.(\d+)\.(\d+)\.(\d+)', s or '')
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 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():
try:
import winreg
except Exception:
return None, None
reg_paths = [
(winreg.HKEY_CURRENT_USER, r'Software\Google\Chrome\BLBeacon'),
(winreg.HKEY_LOCAL_MACHINE, r'SOFTWARE\Google\Chrome\BLBeacon'),
(winreg.HKEY_LOCAL_MACHINE, r'SOFTWARE\WOW6432Node\Google\Chrome\BLBeacon'),
]
for hive, path in reg_paths:
try:
with winreg.OpenKey(hive, path) as key:
version, _ = winreg.QueryValueEx(key, 'version')
pv = parse_version(version)
if pv:
return version, 'registry:' + path
except Exception:
pass
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 exe in candidates:
if exe and os.path.exists(exe):
out = run_cmd([exe, '--version'])
pv = parse_version(out)
if pv:
return '.'.join(str(x) for x in pv), exe
return None, None
def get_macos_version():
app = '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'
if os.path.exists(app):
out = run_cmd([app, '--version'])
pv = parse_version(out)
if pv:
return '.'.join(str(x) for x in pv), app
return None, None
def get_linux_version():
cmds = [
['google-chrome', '--version'],
['google-chrome-stable', '--version'],
['chromium-browser', '--version'],
['chromium', '--version'],
]
for cmd in cmds:
out = run_cmd(cmd)
pv = parse_version(out)
if pv:
return '.'.join(str(x) for x in pv), cmd[0]
return None, None
def main():
system = platform.system().lower()
version = None
source = None
if 'windows' in system:
version, source = get_windows_version()
elif 'darwin' in system:
version, source = get_macos_version()
elif 'linux' in system:
version, source = get_linux_version()
if not version:
print('UNKNOWN - Google Chrome version not found on this host')
sys.exit(2)
pv = parse_version(version)
if not pv:
print(f'UNKNOWN - Unable to parse version: {version}')
sys.exit(2)
if cmp_ver(pv, FIXED) < 0:
print(f'VULNERABLE - Detected Chrome {version} via {source}; fixed version is 149.0.7827.53 or later')
sys.exit(1)
else:
print(f'PATCHED - Detected Chrome {version} via {source}; fixed version is 149.0.7827.53 or later')
sys.exit(0)
if __name__ == '__main__':
main()
If you remember one thing.
149.0.7827.53+, and, if you have cheap policy wins, tighten RAR handling at mail/web boundaries. Because this is LOW, there is no noisgate mitigation SLA and no noisgate remediation SLA — treat it as backlog hygiene; fold it into the next standard browser update wave and validate closure with endpoint version checks rather than incident-style response.Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.