This is a bad ID check at the lobby door, not someone blowing the vault open
CVE-2026-11036 is a DOM-layer same-origin-policy bypass in Google Chrome before 149.0.7827.53 on Linux and 149.0.7827.53/.54 on Windows/macOS. The attacker has to get a user onto a crafted HTML page, and the bug lives inside the browser’s handling of origin boundaries rather than delivering code execution or a sandbox escape.
Google tagged it MEDIUM with CVSS 6.5, and that is technically defensible in a vacuum because breaking origin boundaries can let an attacker drive actions inside a victim’s authenticated web sessions. But for enterprise patch triage, the real-world chain is narrower: it is *client-side*, needs *user interaction*, has *no known in-the-wild exploitation*, has *extremely low EPSS*, and does *not* turn into device takeover by itself. That pushes this down into backlog hygiene, not emergency response.
3 steps from start to impact.
Land the victim on attacker-controlled content
- Target is using Google Chrome prior to
149.0.7827.53 - Attacker can get the user to open a malicious page
- Browser has not yet auto-updated or been restarted into the fixed build
- Requires user interaction (
UI:R), which immediately removes drive-by-at-scale certainty - Chrome auto-update reduces dwell time on unmanaged stale builds
- Enterprise mail, DNS, SWG, and browser isolation stacks can block the delivery path before rendering
Trigger the DOM origin-validation flaw
497964917; public details were still restricted when Google published the fix, which is normal for Chrome releases. Without a public write-up, defenders should assume exploit reliability is not trivial but also not impossible.- Specific vulnerable DOM code path is reachable from web content
- Exploit logic works against the victim’s exact Chrome build and platform
- No renderer-hardening or timing differences break the crafted sequence
- Bug details are restricted, so copy-paste exploitation is less likely right now
- DOM/SOP bypasses often need precise browser-state assumptions and are less portable than simple memory-corruption bugs
- No evidence this bug bypasses sandbox or OS boundaries
Abuse the victim browser’s authenticated session
I:H and C:N CVSS profile more than full data theft or host compromise.- Victim is simultaneously authenticated to a relevant target application
- The target application performs meaningful actions through the reachable browser context
- The app’s own anti-abuse controls do not stop the resulting requests
- Blast radius is user-session scoped, not enterprise-wide infrastructure takeover
- Modern SaaS apps may require step-up auth, CSRF defenses, re-auth prompts, or confirmation flows for sensitive actions
- No direct persistence or privilege escalation on the endpoint from this CVE alone
The supporting signals.
| In-the-wild status | No public evidence of active exploitation found in consulted sources; not KEV-listed. |
|---|---|
| PoC availability | No public proof-of-concept located in primary or reputable secondary sources at assessment time; Chromium bug details appear restricted via issue 497964917. |
| EPSS | 0.00016 from the user-provided intel; that is extremely low predicted near-term exploitation probability. Percentile was not verified from consulted sources. |
| KEV status | No entry for CVE-2026-11036 in the CISA KEV catalog. |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N — remote and low-complexity, but gated by user interaction and limited to integrity impact rather than code execution. |
| Affected versions | Google Chrome prior to 149.0.7827.53; Chrome stable release notes specify 149.0.7827.53 for Linux and 149.0.7827.53/.54 for Windows and macOS. |
| Fixed versions | Upgrade to Chrome 149.0.7827.53 or later on Linux, and 149.0.7827.53/.54 or later on Windows/macOS. |
| Exposure/scanning reality | This is not internet-enumerable in the usual Shodan/Censys sense because it is a client-side browser flaw, not a listening network service. Exposure measurement is an asset inventory / browser version problem, not an external attack-surface scan problem. |
| Disclosure timeline | Chrome stable update published 2026-06-02; NVD published the CVE on 2026-06-04 and CISA-ADP added CVSS/CWE on 2026-06-05. |
| Reporter | Reported by Google on 2026-03-30 per the Chrome stable channel advisory. |
noisgate verdict.
The decisive downgrade factor is that this bug is post-click client-side abuse, not unauthenticated remote compromise of a server or endpoint. It needs a victim on a stale Chrome build to visit attacker content, and even then the impact stays inside browser trust boundaries rather than becoming system takeover.
Why this verdict
- Downward adjustment: requires user interaction — the attacker must get a user to open crafted web content, so this is not a blind unauthenticated internet smash-and-grab.
- Downward adjustment: client-side only — there is no server exposure population to sweep with scanners; reach depends on stale browser versions on endpoints and a successful delivery channel.
- Downward adjustment: blast radius is session-scoped — even if exploited, the likely impact is misuse of the victim’s web session, not endpoint code execution or domain-wide compromise from this CVE alone.
- Downward adjustment: no exploitation signal — no KEV entry, no public campaign reporting, and the provided EPSS
0.00016all argue against urgent attacker demand. - Downward adjustment: bug details restricted — with the Chromium issue still closed/restricted, opportunistic commodity exploitation is less likely in the short term.
Why not higher?
This does not present like a broad enterprise-compromise primitive. There is no evidence here of sandbox escape, code execution, credential dumping, or a network-reachable server foothold, and the attack chain starts with convincing a user to browse attacker content. That is too much friction for HIGH or CRITICAL patch priority in a 10,000-host environment.
Why not lower?
It still breaks a core browser trust boundary: same-origin policy. If a victim is logged into important internal or SaaS applications, a successful exploit could still tamper with business data or drive unauthorized actions in that user context. That is enough to keep it above IGNORE.
What to do — in priority order.
- Enforce browser auto-update — Make sure Chrome auto-update is enabled and that managed endpoints actually relaunch into the new build. For a
LOWverdict there is no SLA deadline, but this is still the cleanest control because stale browser versions are the whole exposure condition. - Block unsupported/stale Chrome builds — Use endpoint posture checks, MDM, or EDR inventory to flag Chrome versions below
149.0.7827.53and push users to update. ForLOW, treat this as backlog hygiene rather than an emergency change. - Lean on browser isolation and secure web gateways — Remote browser isolation, DNS filtering, and SWG controls cut off the most likely initial condition: loading attacker-controlled HTML. They reduce exploit opportunity immediately even before every endpoint finishes normal update cadence.
- Harden sensitive apps with step-up auth — For high-value internal and SaaS workflows, require re-authentication or MFA for destructive actions so a browser-session abuse bug has less room to cause damage. This matters most for finance, admin, and identity consoles.
- Perimeter vulnerability scanning does not solve this well, because Chrome is a client application and not externally fingerprintable like a server daemon.
- A WAF in front of your web apps is not a primary control here, because the vulnerable component is the victim browser rendering attacker content.
- Network segmentation is mostly irrelevant to the initial exploit path; the attacker comes through normal web browsing, not lateral movement to a listening service.
Crowdsourced verification payload.
Run this on the target endpoint or through your endpoint management tooling, not from an auditor workstation. Invoke it as python3 check_chrome_cve_2026_11036.py on macOS/Linux or py check_chrome_cve_2026_11036.py on Windows; standard user rights are usually enough, though locked-down Windows registry access may require local read access.
#!/usr/bin/env python3
# Check for CVE-2026-11036 exposure based on installed Google Chrome version.
# Outputs one of: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
import os
import platform
import plistlib
import re
import shutil
import subprocess
import sys
FIXED_VERSION = "149.0.7827.53"
def parse_version(v):
parts = re.findall(r"\d+", v or "")
if not parts:
return None
return tuple(int(x) for x in parts)
def cmp_version(a, b):
va = parse_version(a)
vb = parse_version(b)
if va is None or vb is None:
return None
max_len = max(len(va), len(vb))
va = va + (0,) * (max_len - len(va))
vb = vb + (0,) * (max_len - len(vb))
if va < vb:
return -1
if va > vb:
return 1
return 0
def run_cmd(cmd):
try:
p = subprocess.run(cmd, capture_output=True, text=True, timeout=10)
if p.returncode == 0:
return (p.stdout or p.stderr).strip()
except Exception:
pass
return None
def extract_version(text):
if not text:
return None
m = re.search(r"(\d+\.\d+\.\d+\.\d+)", text)
return m.group(1) if m else None
def get_linux_version():
candidates = [
["google-chrome", "--version"],
["google-chrome-stable", "--version"],
["/opt/google/chrome/chrome", "--version"],
["chromium-browser", "--version"],
["chromium", "--version"],
]
for cmd in candidates:
exe = cmd[0]
if exe.startswith("/") or shutil.which(exe):
out = run_cmd(cmd)
ver = extract_version(out)
if ver:
return ver
return None
def get_macos_version():
plist_paths = [
"/Applications/Google Chrome.app/Contents/Info.plist",
os.path.expanduser("~/Applications/Google Chrome.app/Contents/Info.plist"),
]
for path in plist_paths:
if os.path.exists(path):
try:
with open(path, "rb") as f:
data = plistlib.load(f)
ver = data.get("KSVersion") or data.get("CFBundleShortVersionString")
if ver:
return ver
except Exception:
pass
return None
def get_windows_version():
reg_queries = [
["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 reg_queries:
out = run_cmd(cmd)
ver = extract_version(out)
if ver:
return ver
file_candidates = [
os.path.join(os.environ.get("ProgramFiles", r"C:\Program Files"), r"Google\Chrome\Application\chrome.exe"),
os.path.join(os.environ.get("ProgramFiles(x86)", r"C:\Program Files (x86)"), r"Google\Chrome\Application\chrome.exe"),
os.path.join(os.environ.get("LOCALAPPDATA", ""), r"Google\Chrome\Application\chrome.exe"),
]
for path in file_candidates:
if path and os.path.exists(path):
out = run_cmd([path, "--version"])
ver = extract_version(out)
if ver:
return ver
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()
else:
print("UNKNOWN - unsupported platform: {}".format(platform.system()))
sys.exit(2)
if not version:
print("UNKNOWN - Google Chrome version not found")
sys.exit(2)
cmp_result = cmp_version(version, FIXED_VERSION)
if cmp_result is None:
print("UNKNOWN - unable to parse installed version: {}".format(version))
sys.exit(2)
if cmp_result < 0:
print("VULNERABLE - installed Chrome version {} is older than fixed {}".format(version, FIXED_VERSION))
sys.exit(1)
else:
print("PATCHED - installed Chrome version {} is at or above fixed {}".format(version, FIXED_VERSION))
sys.exit(0)
if __name__ == "__main__":
main()
If you remember one thing.
LOW noisgate verdict there is no noisgate mitigation SLA and no noisgate remediation SLA beyond normal backlog hygiene, so the practical move is to verify Chrome auto-update health, identify any endpoints still below 149.0.7827.53, and roll them into routine browser maintenance rather than an emergency campaign.Sources
- NVD entry for CVE-2026-11036
- Google Chrome Stable Channel Update for Desktop (June 2, 2026)
- Google Chrome Early Stable Update for Desktop (May 29, 2026)
- Chromium issue reference 497964917
- CISA Known Exploited Vulnerabilities Catalog
- FIRST EPSS API documentation
- GovCERT.HK alert on Chrome 149 vulnerabilities
- SecurityWeek coverage of Chrome 149 patch release
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.