01 · The Real Story
This is a side door inside a side room, not the front gate to the browser
CVE-2026-11187 is an access-control flaw in Chrome's Glic feature that lets a remote attacker bypass navigation restrictions using crafted web content. The affected range is Google Chrome prior to 149.0.7827.53 on Linux and prior to 149.0.7827.53/.54 on desktop builds, with disclosure on 2026-06-04. Practically, this is not a generic browser RCE or sandbox escape; it is a policy/boundary failure in a newer AI-adjacent Chrome component.
Google's MEDIUM 6.3 is fair in a lab sense, but it overstates enterprise urgency. The biggest downward pressure is deployment reality: Glic is a relatively new feature, its rollout has been limited, and exploitation still depends on user interaction plus the victim actually having the relevant feature surface enabled and reachable. No KEV listing, no public exploitation evidence, and a tiny EPSS all point to a low-priority browser hygiene issue rather than an active intrusion path.
"This is a niche Chrome AI sidebar boundary slip, not a fleet-wide browser fire."
02 · The Attack Path
4 steps from start to impact.
STEP 01
Land the victim on attacker-controlled web content
The attacker needs a user to open a malicious page, link, or embedded content in a vulnerable Chrome build. The initial delivery mechanism is standard web luring, not a self-propagating exploit, and the payload still has to exercise the Glic-specific navigation path.
Conditions required:
- Victim is using Chrome before 149.0.7827.53
- Victim opens attacker-controlled content
- JavaScript or browser-driven navigation is allowed
Where this breaks in practice:
- Requires user interaction
- Commodity phishing protections, Safe Browsing, mail filtering, and URL rewriting can break delivery
- Many enterprises aggressively auto-update Chrome
Detection/coverage: Web proxies, email security, and browser telemetry can catch lure delivery, but scanners generally do not validate this logic flaw remotely.
STEP 02
Reach the Glic feature surface
The malicious content must interact with the Glic workflow rather than ordinary browsing alone. That means the target population is narrower than 'all Chrome users' because the feature has had limited rollout and may be disabled, unavailable, unsupported, or unused in enterprise fleets.
Conditions required:
- Glic is present in the installed Chrome build
- The user is eligible for and able to invoke the feature
- Enterprise policy does not disable the feature
Where this breaks in practice:
- Feature rollout has been limited
- Enterprises may suppress experimental or AI-assisted browser features
- A large share of corporate browsing sessions will never touch Glic
Detection/coverage: Inventory and policy telemetry are your best coverage here; external scanners cannot determine feature enablement reliably.
STEP 03
Abuse the navigation restriction bypass
Using crafted navigation behavior, the attacker bypasses intended restrictions inside the Glic context. The likely effect is crossing a UI or navigation boundary that should have prevented certain page transitions or destinations, not arbitrary code execution on the endpoint.
Conditions required:
- The crafted content triggers the vulnerable navigation path
- The browser enforces the flawed restriction logic in that session
Where this breaks in practice:
- The flaw appears scoped to a specific Chrome subsystem
- No public exploit chain or reliable weaponization details are broadly available
- Browser logic bugs often behave inconsistently across feature states and channels
Detection/coverage: Behavioral browser logging may show unusual
chrome://glic or feature-specific navigation events, but off-the-shelf scanners are weak here.STEP 04
Convert boundary bypass into meaningful impact
After the bypass, the attacker still has to turn that access into data exposure, unwanted actions, or user deception. With vendor CVSS set to low confidentiality, integrity, and availability impact, the likely blast radius is modest and user-context-bound.
Conditions required:
- Useful data or functionality is reachable through the bypassed path
- The victim remains engaged long enough for follow-on actions
Where this breaks in practice:
- Impact is constrained compared with RCE, sandbox escape, or account takeover
- Any sensitive action may still require separate user consent, login state, or same-site protections
- EDR will not stop a UI-boundary flaw directly, but browser isolation and SSO controls reduce downstream value
Detection/coverage: Look for anomalous browser childless activity, navigation to unusual internal surfaces, and user-reported browser oddities; vulnerability scanners will mostly reduce to version checking.
03 · Intelligence Metadata
The supporting signals.
| In-the-wild status | No public evidence of active exploitation found, and CISA KEV does not list it as of this assessment. Source: CISA KEV catalog |
|---|---|
| Proof-of-concept availability | No credible public PoC or exploit repo for CVE-2026-11187 was found in primary-source review. That lowers immediate weaponization risk. |
| EPSS | 0.00023 from the user-provided intel, which is extremely low and consistent with a niche client-side logic bug rather than a broadly exploited enterprise foothold. |
| KEV status | Not KEV-listed; no known CISA due date pressure applies. Source: CISA KEV catalog |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:L — remote and unauthenticated, but user interaction is required and the impacts stay low across C/I/A. |
| Affected versions | Chrome prior to 149.0.7827.53 per the CVE description; Google's desktop release note shows 149.0.7827.53/.54 for Windows and Mac as the relevant fixed train. Source: Chrome Releases |
| Fixed versions | Patch to 149.0.7827.53 on Linux and 149.0.7827.53/.54 on Windows/Mac desktop channels. Source: Chrome Releases |
| Exposure reality | This is a client-side browser flaw, so Shodan/Censys/FOFA exposure counts are not meaningful. The reachable population is further narrowed because Glic/Gemini in Chrome has been a staged feature rollout rather than a universal enterprise control plane. Sources: Chrome AI announcement, Chromium Glic source tree |
| Disclosure date | 2026-06-04 from the supplied CVE intel. |
| Researcher / reporting | Public credit was not clearly exposed in the sources reviewed. Treat reporter attribution as undisclosed/unclear unless the CVE record is later expanded at CVE.org or NVD. |
04 · The Call
noisgate verdict.
Final Verdict
↓ DOWNGRADED to LOW (3.2/10)
The decisive factor is population narrowing: this requires a vulnerable Chrome build, user interaction, and a reachable Glic feature path that many enterprise users will never hit. That makes it a browser hygiene issue, not a high-confidence intrusion primitive for a 10,000-endpoint fleet.
HIGH Version-based remediation target
MEDIUM Operational impact and exploitability assessment
Why this verdict
- Downward adjustment: requires user interaction — this starts with lure-and-click or attacker-controlled content, so modern email/web controls remove a chunk of the reachable population before the bug is ever exercised.
- Downward adjustment: Glic-specific attack surface — the flaw is not in core rendering, JavaScript, or the sandbox; it sits in a narrower Chrome feature path with materially lower fleet exposure.
- Downward adjustment: post-delivery blast radius is modest — the vendor vector already signals only low C/I/A impact, and there is no evidence this becomes code execution, sandbox escape, or account compromise by itself.
- Downward adjustment: no active exploitation signals — not KEV-listed, no public exploit campaign, and an EPSS of 0.00023 argue against urgent attacker interest.
- Residual risk remains — Chrome is everywhere, and even niche browser logic bugs can matter at scale if your org leaves old versions around.
Why not higher?
This is not a wormable bug, not an unauthenticated server-side exposure, and not a browser RCE. The chain is gated by user interaction and by a feature-specific path that sharply reduces how many real enterprise sessions are actually exposed.
Why not lower?
It is still a remotely triggerable browser flaw in widely deployed software, and version drift across unmanaged or slow-updating endpoints is common. If you have Chrome populations that use new AI/browser-assistant features, the bug is real enough to patch rather than dismiss.
05 · Compensating Control
What to do — in priority order.
- Force Chrome auto-update — Make sure managed endpoints are pulling Chrome 149.0.7827.53 or later and that update channels are not pinned behind the fix. For a LOW verdict there is no formal mitigation SLA, so use normal browser hygiene and close it in the next routine update wave.
- Disable or restrict Glic where unused — If your fleet does not need Chrome's Glic/Gemini surface, disable or limit it through enterprise browser policy to remove the vulnerable feature path entirely. For LOW severity, do this opportunistically during your next policy maintenance window rather than as emergency change work.
- Harden click-path defenses — Keep Safe Browsing, secure web gateway filtering, and email link protections enabled because the exploit still needs user-driven delivery. This is a standing control, not an emergency mitigation, and it reduces the practical chance of the bug ever being exercised.
- Audit version laggards — Use EDR, software inventory, or browser management telemetry to find endpoints stuck below 149.0.7827.53 and clean those up first. With a LOW verdict, handle exceptions as backlog hygiene, but do not let stale Chrome rings linger indefinitely.
What doesn't work
- Endpoint AV alone does not stop a browser navigation-policy flaw; there may be no dropped file or suspicious process tree to catch.
- Network perimeter scanning will not meaningfully find this exposure because the vulnerable surface is client-side and tied to local browser feature state.
- MFA is irrelevant to the initial exploit path; it only helps if a later attacker action tries to pivot into account abuse.
06 · Verification
Crowdsourced verification payload.
Run this on the target endpoint itself, or via your EDR/remote shell tooling, to verify the locally installed Chrome version. Invoke it with python3 check_cve_2026_11187.py; no admin rights are usually required, though endpoint management tools may need standard local execution permissions.
#!/usr/bin/env python3\n# check_cve_2026_11187.py\n# Exit codes:\n# 0 = PATCHED\n# 1 = VULNERABLE\n# 2 = UNKNOWN\n\nimport os\nimport platform\nimport re\nimport shutil\nimport subprocess\nimport sys\n\nFIXED = (149, 0, 7827, 53)\n\ndef parse_version(text):\n m = re.search(r'(\d+)\.(\d+)\.(\d+)\.(\d+)', text)\n if not m:\n return None\n return tuple(int(x) for x in m.groups())\n\ndef version_ge(a, b):\n return a >= b\n\ndef run_cmd(cmd):\n try:\n p = subprocess.run(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True, timeout=10)\n out = (p.stdout or '') + '\\n' + (p.stderr or '')\n return out.strip()\n except Exception:\n return ''\n\ndef detect_linux():\n candidates = [\n 'google-chrome',\n 'google-chrome-stable',\n 'chromium',\n 'chromium-browser',\n ]\n for c in candidates:\n path = shutil.which(c)\n if path:\n out = run_cmd([path, '--version'])\n v = parse_version(out)\n if v:\n return ('Linux', path, v, out)\n return None\n\ndef detect_macos():\n candidates = [\n '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',\n os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),\n ]\n for path in candidates:\n if os.path.exists(path):\n out = run_cmd([path, '--version'])\n v = parse_version(out)\n if v:\n return ('macOS', path, v, out)\n return None\n\ndef detect_windows():\n commands = []\n local = os.environ.get('LOCALAPPDATA', '')\n program_files = os.environ.get('PROGRAMFILES', '')\n program_files_x86 = os.environ.get('PROGRAMFILES(X86)', '')\n\n paths = [\n os.path.join(local, 'Google', 'Chrome', 'Application', 'chrome.exe'),\n os.path.join(program_files, 'Google', 'Chrome', 'Application', 'chrome.exe'),\n os.path.join(program_files_x86, 'Google', 'Chrome', 'Application', 'chrome.exe'),\n ]\n\n for path in paths:\n if path and os.path.exists(path):\n out = run_cmd([path, '--version'])\n v = parse_version(out)\n if v:\n return ('Windows', path, v, out)\n\n reg_queries = [\n ['reg', 'query', r'HKCU\\Software\\Google\\Chrome\\BLBeacon', '/v', 'version'],\n ['reg', 'query', r'HKLM\\Software\\Google\\Chrome\\BLBeacon', '/v', 'version'],\n ['reg', 'query', r'HKLM\\Software\\WOW6432Node\\Google\\Chrome\\BLBeacon', '/v', 'version'],\n ]\n for q in reg_queries:\n out = run_cmd(q)\n v = parse_version(out)\n if v:\n return ('Windows', 'registry', v, out)\n return None\n\ndef main():\n system = platform.system()\n result = None\n\n if system == 'Linux':\n result = detect_linux()\n elif system == 'Darwin':\n result = detect_macos()\n elif system == 'Windows':\n result = detect_windows()\n else:\n print('UNKNOWN: unsupported platform {}'.format(system))\n sys.exit(2)\n\n if not result:\n print('UNKNOWN: Google Chrome not found or version unreadable')\n sys.exit(2)\n\n os_name, source, version, raw = result\n version_str = '.'.join(str(x) for x in version)\n fixed_str = '.'.join(str(x) for x in FIXED)\n\n if version_ge(version, FIXED):\n print('PATCHED: {} Chrome version {} detected via {}'.format(os_name, version_str, source))\n sys.exit(0)\n else:\n print('VULNERABLE: {} Chrome version {} detected via {}; fixed is {}'.format(os_name, version_str, source, fixed_str))\n sys.exit(1)\n\nif __name__ == '__main__':\n main()\n07 · Bottom Line
If you remember one thing.
TL;DR
Monday morning: do not burn emergency change budget on this one unless you have a specific business reason to keep vulnerable Chrome builds in place while also enabling Glic. For a LOW verdict there is no noisgate mitigation SLA and no noisgate remediation SLA beyond backlog hygiene, so document the downgrade rationale, make sure Chrome auto-update is healthy, and fold any laggards below 149.0.7827.53 into your next routine browser patch wave; if you do not use Glic, disable it during the same normal policy cycle.
Sources
Peer Review
What defenders are saying.
Submit a review
attribution: handle + country only
0 flags selected · stored anonymously
Validation Results
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.