Like a hallway pass that lets a visitor slip past the wrong door without giving them the building keys
CVE-2026-11184 is an *insufficient policy enforcement* bug in Chrome's Actor component that affects Chrome versions prior to 149.0.7827.53 on Linux and 149.0.7827.53/54 on Windows and macOS. The published impact is *bypass navigation restrictions* via a crafted HTML page, which means a malicious site can make the browser perform a navigation the platform policy should have blocked.
Google rated it MEDIUM at 6.3, and that is defensible in a vacuum, but it still overstates the operational urgency for enterprise patch triage. This is client-side, requires user interaction, has no published RCE/data-theft primitive in the advisory, no KEV listing, no public exploit chain, and the practical outcome is policy bypass rather than code execution or sandbox escape.
3 steps from start to impact.
Land the user on attacker-controlled HTML
- Victim uses Chrome prior to
149.0.7827.53 - Victim opens attacker-controlled content
- The browsing session is not already blocked by upstream web filtering or Safe Browsing
- Requires user interaction (
UI:R) - Email gateways, secure web gateways, and browser reputation systems often block first-stage delivery
- This is not a passive network bug; the attacker must win a click
Trigger the navigation-policy bypass
Actor policy-enforcement weakness to force or allow a navigation that Chrome should have restricted. The practical 'tool' is custom JavaScript/HTML, but the underlying implementation details remain restricted in the Chromium issue, which is a signal that public weaponization is not yet trivial.- The vulnerable code path in
Actoris reachable from normal web content - The page can invoke the specific navigation scenario the bug affects
- Bug details are still restricted, limiting turnkey exploit reproduction
- Navigation-restriction bypasses are usually narrower than generic XSS or UXSS primitives
- Modern site isolation and browser hardening reduce blast radius if the bypass does not chain into a stronger primitive
Convert policy bypass into real-world abuse
- The bypass meaningfully alters the user's trusted browsing context
- A target workflow exists where redirected or disallowed navigation creates business impact
- The advisory does not claim code execution, sandbox escape, or cross-origin data theft
- Business impact depends on follow-on abuse rather than the bug alone
- MFA, IdP risk controls, and user-visible domain changes blunt many phishing-style outcomes
The supporting signals.
| In-the-wild status | No public evidence of active exploitation found in the checked sources, and it is not listed in the CISA KEV catalog. |
|---|---|
| Proof-of-concept availability | No reliable public PoC or GitHub exploit surfaced in source review. The linked Chromium issue is sign-in restricted, which usually slows casual weaponization. |
| EPSS | Upstream intel supplied 0.00031, which is extremely low and consistent with a low-likelihood browser policy-bypass rather than a mass-exploitation bug. EPSS should not drive severity alone, but here it supports the downgrade. |
| KEV status | Not KEV-listed when checked against CISA's authoritative catalog; no date added applies. |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:L from the supplied vendor intel. The key limiter is UI:R: the attacker needs the user in the loop. |
| Affected versions | Chrome prior to 149.0.7827.53 on Linux and prior to 149.0.7827.53/54 on Windows/macOS per the Chrome stable release note. |
| Fixed versions | Upgrade to 149.0.7827.53 or later on Linux, and 149.0.7827.53/54 or later on Windows/macOS. For enterprise-managed channels, validate the exact build delivered by your browser management platform. |
| Exposure data | There is no meaningful Shodan/Censys/FOFA-style internet census for endpoint browser versions, so exposure must be measured from MDM, EDR, SCCM/Intune/Jamf, or Chrome enterprise reporting. This is a *fleet inventory* problem, not an internet-exposure problem. |
| Disclosure date | Publicly disclosed 2026-06-04; the stable desktop fix shipped on June 2, 2026 in Chrome 149.0.7827.53/.54, and the CVE record appeared on June 4, 2026. |
| Reporter | Reported by Google on 2026-04-15 in the release advisory; no external researcher credit is listed for this CVE. |
noisgate verdict.
The decisive factor is that this bug is a *user-driven browser policy bypass* with no published RCE, sandbox escape, or data-exfiltration primitive. In practice, it behaves more like a phishing or workflow-confusion enabler than a direct compromise path, so it does not deserve the same queue position as remotely exploitable server bugs or high-confidence browser code-exec flaws.
Why this verdict
- User interaction is mandatory: the attacker must get a victim onto crafted HTML, which means this starts after a successful lure or ad-delivery event.
- The bug class is narrow: the advisory describes *bypass navigation restrictions*, not code execution, sandbox escape, or origin-crossing data theft.
- No exploitation signal: no KEV listing, no public campaign reporting, and no public PoC reduces the urgency multiplier that would otherwise keep this in MEDIUM.
- Browser-only blast radius: impact stays in the user's browsing context unless chained with social engineering or another vulnerability.
- Exposure is broad but shallow: Chrome is everywhere, but widespread installation is not the same as high-severity exploitability when every attack still depends on user interaction and a narrow browser behavior flaw.
Why not higher?
There is no published evidence that this flaw alone yields code execution, sandbox escape, account takeover, or silent data extraction. The entire chain depends on the victim opening crafted content and the attacker successfully converting a navigation-policy bypass into something materially damaging.
Why not lower?
It still affects a massively deployed client application and can plausibly assist phishing, redirect abuse, or web-security boundary confusion at scale. If your environment has many unmanaged browsers or weak browser-update hygiene, the exposure population can still be large enough that this should not be ignored entirely.
What to do — in priority order.
- Enforce browser auto-update — Make sure Chrome stable auto-update is functioning across managed Windows, macOS, and Linux endpoints. For a
LOWverdict, treat this as backlog hygiene and complete it in your normal browser maintenance cycle rather than opening an incident lane. - Block high-risk web delivery paths — Use SWG/DNS filtering, category controls, and Safe Browsing policy enforcement to reduce first-stage delivery of malicious landing pages. This is the best temporary control because the attack begins with a user opening crafted content.
- Harden identity flows — Require phishing-resistant MFA where possible and keep IdP risk policies tuned for suspicious redirects and anomalous sign-ins. That limits the value of any navigation-confusion or redirect abuse the attacker tries to derive from the browser flaw.
- Inventory out-of-date Chrome builds — Use EDR, MDM, SCCM, Intune, Jamf, or package inventory to find hosts still below
149.0.7827.53. For aLOWverdict, there is no fixed mitigation SLA; keep this in routine hygiene and drive closure through your standard patch governance.
- Network perimeter blocking alone does not solve this, because the trigger is ordinary web content delivered over normal browsing paths.
- EDR malware signatures will not reliably catch a logic flaw in browser navigation enforcement; there may be no malware artifact at all.
- Server-side patching is irrelevant here; the vulnerable component is the endpoint browser, so internet-facing appliance patching does nothing.
Crowdsourced verification payload.
Run this on the target endpoint or through your software-distribution/EDR script runner. Invoke it as python3 chrome_cve_2026_11184_check.py on macOS/Linux or py chrome_cve_2026_11184_check.py on Windows; no admin rights are required for standard install paths, but wider file-system access improves discovery coverage.
#!/usr/bin/env python3
# CVE-2026-11184 Chrome version check
# Outputs: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
import os
import re
import sys
import subprocess
import platform
from pathlib import Path
TARGET = (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 candidate_paths():
paths = []
system = platform.system().lower()
if system == 'windows':
envs = [os.environ.get('ProgramFiles'), os.environ.get('ProgramFiles(x86)'), os.environ.get('LocalAppData')]
rels = [
r'Google\Chrome\Application\chrome.exe',
r'Chromium\Application\chrome.exe'
]
for base in envs:
if base:
for rel in rels:
paths.append(Path(base) / rel)
elif system == 'darwin':
paths.extend([
Path('/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
Path.home() / 'Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
Path('/Applications/Chromium.app/Contents/MacOS/Chromium')
])
else:
paths.extend([
Path('/usr/bin/google-chrome'),
Path('/usr/bin/google-chrome-stable'),
Path('/usr/bin/chromium'),
Path('/usr/bin/chromium-browser'),
Path('/opt/google/chrome/chrome')
])
return paths
def get_version_from_binary(path):
if not path.exists():
return None
out = run_cmd([str(path), '--version'])
return parse_version(out)
def get_windows_registry_version():
keys = [
r'HKLM\Software\Google\Chrome\BLBeacon',
r'HKLM\Software\WOW6432Node\Google\Chrome\BLBeacon',
r'HKCU\Software\Google\Chrome\BLBeacon'
]
for key in keys:
out = run_cmd(['reg', 'query', key, '/v', 'version'])
ver = parse_version(out)
if ver:
return ver
return None
def discover_version():
system = platform.system().lower()
if system == 'windows':
ver = get_windows_registry_version()
if ver:
return ver, 'registry'
for path in candidate_paths():
ver = get_version_from_binary(path)
if ver:
return ver, str(path)
common_cmds = ['google-chrome', 'google-chrome-stable', 'chromium', 'chromium-browser', 'chrome']
for cmd in common_cmds:
out = run_cmd([cmd, '--version'])
ver = parse_version(out)
if ver:
return ver, cmd
return None, None
def main():
ver, source = discover_version()
if not ver:
print('UNKNOWN - Chrome/Chromium version not found')
sys.exit(2)
ver_str = '.'.join(str(x) for x in ver)
if cmp_ver(ver, TARGET) < 0:
print(f'VULNERABLE - detected version {ver_str} from {source}; needs >= 149.0.7827.53')
sys.exit(1)
else:
print(f'PATCHED - detected version {ver_str} from {source}; meets >= 149.0.7827.53')
sys.exit(0)
if __name__ == '__main__':
main()
If you remember one thing.
149.0.7827.53, confirm auto-update health, and fold remediation into your normal browser ring deployment; for a LOW verdict there is no noisgate mitigation SLA and you should treat it as backlog hygiene, while the noisgate remediation SLA is also backlog-oriented with no fixed deadline. If your browser fleet is badly behind or largely unmanaged, accelerate locally, but this still belongs well below any server-side RCE, KEV-listed item, or browser sandbox escape in the queue.Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.