This is a crack in Chrome’s blast door, not an open front gate
CVE-2026-11179 is an ORB (*Opaque Resource Blocking*) implementation flaw in Google Chrome that affects versions prior to 149.0.7827.53 and can let a malicious site weaken Chrome’s site-isolation protections using crafted HTML. In plain English: a hostile webpage may be able to coax Chrome into mishandling cross-origin resource protections that are supposed to keep one site from seeing another site’s data inside the browser.
Google’s HIGH 8.8 label is understandable from a generic browser-CVSS lens, but it overstates real enterprise urgency. This is not remote code execution, not a sandbox escape, and not a no-click drive-by host compromise; it is a defense-boundary bypass whose practical value depends on a victim browsing to attacker content *and* having interesting authenticated web sessions or sensitive cross-origin data in reach.
4 steps from start to impact.
Lure the user into attacker-controlled content
UI:R, so nothing happens until the page is opened.- Victim uses Chrome older than
149.0.7827.53 - Victim visits attacker-controlled or attacker-influenced web content
- Requires user interaction, so this is not wormable or ambient internet scanning territory
- Enterprise URL filtering, safe browsing, email controls, and browser isolation can break delivery before exploitation
Trigger the ORB bypass with crafted HTML/JS
- Target page path must hit the vulnerable ORB behavior
- The attacker must understand the browser’s cross-origin fetch and rendering edge cases well enough to build a working trigger
- Chrome security bugs often have restricted bug details during rollout, which slows casual copycat weaponization
- No public exploit repo or off-the-shelf module was located in this assessment
Reach sensitive cross-origin browser data
- Victim must have relevant authenticated sessions or sensitive browser-reachable content
- The target resource must be reachable in a way the ORB bypass can abuse
- No active SaaS/admin session means sharply lower payoff
- Data exposure is bounded to browser/session context, not automatic host compromise
Exfiltrate what was exposed
- Attacker must successfully extract useful data from the bypassed boundary
- Outbound web traffic from the browser must be allowed
- The blast radius is narrower than RCE or sandbox escape—mostly web data tied to the browser session
- Modern egress monitoring may still flag unusual browser-to-unknown-domain data movement
The supporting signals.
| In-the-wild status | No CISA KEV listing was found, and no Google statement of active exploitation was located in the reviewed sources. |
|---|---|
| Proof-of-concept availability | No public exploit repo or named researcher write-up was located during this assessment; Chrome also notes bug details may remain restricted until users are updated. |
| EPSS | 0.00028 (~0.028% 30-day exploitation probability). Percentile was not authoritatively verified in the sources reviewed, but the raw score is *extremely low*. |
| KEV status | Not KEV-listed as of this assessment. No CISA due date applies. |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H — the vendor vector treats this like a high-impact client-side browser bug, but the key real-world brake is UI:R plus the fact that impact is a *site-isolation bypass*, not direct code execution. |
| Affected versions | Google Chrome prior to 149.0.7827.53. On desktop, Google’s early stable release moved Windows/macOS to 149.0.7827.53/.54; Linux to 149.0.7827.53. |
| Fixed versions | Upgrade to 149.0.7827.53+ on Linux and 149.0.7827.53/.54+ on Windows/macOS. Chromium downstreams need their own vendor rebuild/backport timing. |
| Exposure / scanning reality | This is a client-side browser flaw, so Shodan/Censys/FOFA-style internet census data is largely *not applicable*. Exposure is your managed endpoint population, not an internet-facing service count. |
| Disclosure date | 2026-06-04 |
| Researcher / reporting | Public credit was not visible in the release material reviewed. |
noisgate verdict.
The decisive downgrade factor is that exploitation still starts with a user browsing to attacker content, and the payoff is a browser isolation failure rather than endpoint takeover. That combination makes this materially less urgent than Chrome RCEs, sandbox escapes, or KEV-listed browser bugs, even though Chrome itself is massively deployed.
Why this verdict
- User interaction drags it down — the attacker needs the victim to open malicious web content, so this is not a server-side internet smash-and-grab.
- This is a boundary bypass, not code execution — ORB/site-isolation failures can be serious, but they usually monetize as cross-origin data access in the browser context, not arbitrary code on the endpoint.
- Low threat telemetry matters — no KEV listing, no public exploitation statement found, and an EPSS of
0.00028all argue against emergency-tier patching. - Blast radius depends on session context — the bug pays off mainly when the victim already has valuable authenticated SaaS or admin sessions open.
- Chrome ubiquity keeps it above LOW — almost every enterprise has a huge Chrome footprint, so even a non-RCE browser bypass deserves scheduled attention.
Why not higher?
There is no verified active exploitation signal here, and the attack path does not end in native code execution, sandbox escape, or direct host compromise. The required conditions compound: vulnerable browser build, user visit, a working ORB trigger, and valuable browser-session data to steal.
Why not lower?
A malicious webpage can still reach this bug remotely with no credentials, and Chrome is one of the largest endpoint attack surfaces in any enterprise. If abused against users with active SaaS or privileged web sessions, the business impact can still be meaningful even without full machine compromise.
What to do — in priority order.
- Enforce browser auto-update and relaunch — Make sure Chrome is centrally pinned to auto-update and that users are forced to relaunch stale instances so the fixed build actually lands. For a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but browser channels should normally close this far sooner than that.
- Isolate high-risk browsing — Route admins, finance, help desk, and other session-rich users through remote browser isolation or hardened browsing profiles where possible. This reduces the value of the bug while you complete patch rollout; for MEDIUM, there is no mitigation SLA — go straight to the 365-day remediation window.
- Separate privileged web activity — Keep administrative SaaS and cloud consoles in dedicated browser profiles or separate managed browsers to reduce session cross-contamination. That limits the blast radius if an employee lands on hostile content before patch completion; for MEDIUM, there is no mitigation SLA — go straight to the 365-day remediation window.
- Watch for unusual browser egress — Tune proxy, CASB, and SaaS detections for odd browser-to-unknown-domain transfers or sudden access bursts after ad clicks, email-link opens, or uncategorized browsing. This will not prevent exploitation, but it gives you a realistic chance to catch the data-movement phase during the remediation window.
- A WAF does not help; the vulnerable logic is in the client browser, not your web server.
- EDR alone is weak here; browser-origin data theft can look like ordinary browser traffic unless exfiltration is noisy.
- Turning on Site Isolation is not a fix for a *site-isolation bypass* flaw; the protection being bypassed is already present.
- Network vuln scanning will not prove exploitability; at best it can inventory outdated Chrome versions on managed endpoints.
Crowdsourced verification payload.
Run this on the target endpoint or through your software inventory/remote execution tooling. Invoke it as python3 check_chrome_cve_2026_11179.py; it needs only normal user read access to local app metadata/registry, not admin, and prints VULNERABLE, PATCHED, or UNKNOWN based on whether the installed Chrome version is older than 149.0.7827.53.
#!/usr/bin/env python3
# check_chrome_cve_2026_11179.py
# Determine whether locally installed Google Chrome is vulnerable to CVE-2026-11179
# Fixed version threshold: 149.0.7827.53
# 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):
if not s:
return None
m = re.search(r'(\d+)\.(\d+)\.(\d+)\.(\d+)', s)
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, capture_output=True, text=True, timeout=10)
out = (p.stdout or '') + '\n' + (p.stderr or '')
return out.strip()
except Exception:
return ''
def get_windows_version():
candidates = [
["reg", "query", r"HKLM\Software\Google\Chrome\BLBeacon", "/v", "version"],
["reg", "query", r"HKLM\Software\WOW6432Node\Google\Chrome\BLBeacon", "/v", "version"],
["reg", "query", r"HKCU\Software\Google\Chrome\BLBeacon", "/v", "version"],
]
for cmd in candidates:
out = run_cmd(cmd)
v = parse_version(out)
if v:
return v
exe_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 exe_candidates:
if os.path.exists(exe):
out = run_cmd([exe, "--version"])
v = parse_version(out)
if v:
return v
return None
def get_macos_version():
app = "/Applications/Google Chrome.app/Contents/MacOS/Google Chrome"
if os.path.exists(app):
out = run_cmd([app, "--version"])
v = parse_version(out)
if v:
return v
plist = "/Applications/Google Chrome.app/Contents/Info.plist"
if os.path.exists(plist):
out = run_cmd(["/usr/bin/defaults", "read", plist, "CFBundleShortVersionString"])
v = parse_version(out)
if v:
return v
return None
def get_linux_version():
bins = [
"google-chrome",
"google-chrome-stable",
"chromium-browser",
"chromium",
]
for b in bins:
out = run_cmd(["/usr/bin/env", b, "--version"])
v = parse_version(out)
if v:
return v
return None
def main():
system = platform.system().lower()
version = None
if "windows" in system:
version = get_windows_version()
elif "darwin" in system:
version = get_macos_version()
elif "linux" in system:
version = get_linux_version()
if not version:
print("UNKNOWN - could not determine installed Chrome version")
sys.exit(2)
if cmp_ver(version, FIXED) < 0:
print("VULNERABLE - installed Chrome version {} is older than {}.{}.{}.{}".format(
".".join(map(str, version)), *FIXED
))
sys.exit(1)
else:
print("PATCHED - installed Chrome version {} meets or exceeds {}.{}.{}.{}".format(
".".join(map(str, version)), *FIXED
))
sys.exit(0)
if __name__ == "__main__":
main()
If you remember one thing.
149.0.7827.53+ under the noisgate remediation SLA of ≤365 days.Sources
- Chrome Releases - Early Stable Update for Desktop (149.0.7827.53/.54)
- Chrome Releases - Chrome Beta for Desktop Update (149.0.7827.53)
- Chromium - Site Isolation overview
- Chromium source - ORB/CORB README
- CISA Known Exploited Vulnerabilities Catalog
- FIRST EPSS API documentation
- SecurityWeek - Chrome 149 patches 429 vulnerabilities
- GovCERT.HK alert - Multiple Vulnerabilities in Google Chrome
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.