This is not a front door break-in, it is a deadbolt someone can flip only after they are already inside the apartment
CVE-2026-11197 is a Chrome *Workers* policy-enforcement flaw that affects Google Chrome versions before 149.0.7827.53. The published description is unusually important: the attacker must have *already compromised the renderer process* and then use a crafted HTML page to bypass same-origin policy from a Worker context. Fixed builds are 149.0.7827.53 on Linux and 149.0.7827.53/54 on Windows and macOS.
Google/NVD call it MEDIUM 6.5, but that overstates standalone enterprise urgency. The decisive friction is the prerequisite: this is not initial access, not unauthenticated remote code execution, and not even a direct sandbox escape. It is a *post-renderer-compromise browser primitive* with no KEV listing, no public exploit code surfaced in the sources reviewed, and a near-floor EPSS signal.
4 steps from start to impact.
Land a separate renderer exploit
- Victim uses a vulnerable Chrome build prior to
149.0.7827.53 - Attacker has a separate renderer-compromise exploit chain
- Victim is lured to attacker-controlled content
- This CVE is not the initial foothold; it assumes the hardest step is already done
- Modern browser hardening, exploit mitigations, and URL filtering reduce commodity success rates
- No public PoC for this CVE was found in the reviewed sources
Trigger Worker code from a crafted page
- Renderer is already compromised
- Worker execution is permitted in the victim browsing context
- Attacker can still drive script execution in the page
- Bug details are restricted, so the exact reachable state is not public
- Enterprise browsing controls, site allowlists, and script restrictions can reduce reachable attack surface
Bypass same-origin policy inside Workers
- The vulnerable Worker policy path must be reachable
- The targeted origin data must be present or accessible in-session
- Chrome Site Isolation and process separation can limit what one compromised renderer can trivially reach
- Many high-value apps still require app-specific tokens and states beyond simple origin access
Abuse the victim's authenticated web session
- Victim is authenticated to a target application
- Target app data is reachable from the exploited context
- Attacker retains sufficient execution stability after the initial renderer exploit
- Blast radius is usually one browser session, not the whole endpoint or fleet
- MFA does not stop session abuse after login, but app-side anti-CSRF and origin checks can still add resistance
The supporting signals.
| In-the-wild status | No evidence of active exploitation in the reviewed sources; CISA ADP enrichment on the CVE record shows Exploitation: none and Automatable: no via CIRCL. |
|---|---|
| KEV status | Not listed in the CISA Known Exploited Vulnerabilities Catalog. |
| Public PoC availability | No public PoC surfaced in the reviewed sources. The Chromium issue is still restricted, and the GitHub advisory says No known source code: Chromium issue, GHSA. |
| EPSS | 0.0002 (~0.016%), roughly 4th-6th percentile depending on feed presentation; both GitHub and CIRCL show a very low exploitation likelihood signal: GHSA, CIRCL. |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N — looks remote on paper, but that hides the real gate: the attacker must already control the renderer. |
| Affected versions | Google Chrome before 149.0.7827.53 per the CVE/CNA data; NVD-enriched data in CIRCL also shows versionEndExcluding 149.0.7827.53: CIRCL. |
| Fixed versions | Chrome 149.0.7827.53 on Linux and 149.0.7827.53/54 on Windows/macOS in Google's stable-channel release: Chrome Releases. |
| Exposure reality | This is a client-side browser flaw, not an internet-routable service defect. Shodan/Censys-style exposure counts are not meaningful here; the relevant exposure metric is simply how many managed endpoints still run Chrome <149.0.7827.53. |
| Disclosure timeline | Published on 2026-06-04 in the CVE/NVD data; the fixing stable-channel release was posted 2026-06-02: CIRCL, Chrome Releases. |
| Reporter | Reported by VEZEKA on 2026-04-19 according to Google's release notes entry for CVE-2026-11197: Chrome Releases. |
noisgate verdict.
The single biggest severity reducer is the attacker position requirement: this bug only helps *after* the renderer is already compromised. That makes it a chain-enabler for high-end browser exploitation, not a fleet-wide initial access risk by itself.
Why this verdict
- Major downgrade for prerequisite: the attacker must have already compromised the renderer process, which implies a prior successful browser exploit stage and sharply narrows real-world reach.
- User-driven delivery: exploitation still depends on the victim loading attacker-controlled HTML, adding another practical gate beyond the prerequisite compromise.
- No exploitation pressure: no KEV listing, no reviewed public PoC, and a near-bottom EPSS score all push this out of urgent patch triage.
- Browser ubiquity prevents IGNORE: Chrome is everywhere, and same-origin policy bypasses are valuable chain primitives when paired with another bug, so this still deserves routine remediation.
Why not higher?
If this were a direct same-origin bypass from a normal web page with no prior compromise, the score would climb fast. But this CVE is explicitly *post-renderer-compromise*, which means an attacker has already cleared the hardest barrier in the chain before this bug even matters.
Why not lower?
It is still a real browser security-boundary failure in a massively deployed client. In targeted attacks, a SOP bypass chained after renderer compromise can convert a browser foothold into access to sensitive authenticated web sessions, so treating it as pure noise would be sloppy.
What to do — in priority order.
- Enforce Chrome auto-update and relaunch — Make sure managed endpoints actually converge to
149.0.7827.53+and force relaunch where your browser-management policy allows it. For a LOW verdict there is no SLA; treat this as standard browser hygiene rather than an emergency change. - Prioritize privileged-user browsing isolation — Apply stronger browser isolation or remote browser isolation to admins, finance users, and users with access to sensitive SaaS, because this CVE only pays off when chained into an already-compromised browsing session. For LOW, fold this into your normal hardening program with no SLA.
- Hunt for lagging versions in VDI and kiosk pools — Chrome drift is common on persistent VDI images, kiosks, and devices with suppressed restarts. Sweep for versions below
149.0.7827.53and clean up those pockets during the next routine endpoint maintenance cycle; no SLA applies for this severity. - Correlate browser crashes with risky browsing telemetry — Because the first stage is likely a separate renderer exploit, unusual Chrome crash spikes, repeated child-process faults, or suspicious web-session telemetry are better early-warning signals than network IOC matching. This is ongoing monitoring work, not an emergency mitigation, for a LOW call.
- Perimeter scanning does not help; this is not an internet-exposed server vulnerability.
- WAF rules do not meaningfully protect local browser Worker behavior on unmanaged internet content.
- MFA alone does not stop session abuse after a browser compromise; it protects login, not a stolen live session.
- Version-only risk inflation is misleading here; seeing a vulnerable Chrome build does not mean the CVE is directly weaponizable without a separate renderer bug.
Crowdsourced verification payload.
Run this on the target endpoint or through your software inventory/remote-exec platform; it checks the locally installed Google Chrome version against the fixed floor for CVE-2026-11197. Invoke it with python3 check_chrome_cve_2026_11197.py on macOS/Linux or py .\check_chrome_cve_2026_11197.py on Windows; no admin rights are usually required, though Windows registry access to both HKLM/HKCU is helpful.
#!/usr/bin/env python3
# check_chrome_cve_2026_11197.py
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
import os
import platform
import re
import subprocess
import sys
PATCHED_FLOOR = (149, 0, 7827, 53)
VERSION_RE = re.compile(r"(\d+)\.(\d+)\.(\d+)\.(\d+)")
def parse_version(text):
if not text:
return None
m = VERSION_RE.search(text)
if not m:
return None
return tuple(int(x) for x in m.groups())
def version_to_str(v):
return ".".join(str(x) for x in v)
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_version_windows():
try:
import winreg
except Exception:
winreg = None
reg_paths = [
("HKEY_CURRENT_USER", r"Software\Google\Chrome\BLBeacon", "version"),
("HKEY_LOCAL_MACHINE", r"Software\Google\Chrome\BLBeacon", "version"),
("HKEY_LOCAL_MACHINE", r"Software\WOW6432Node\Google\Chrome\BLBeacon", "version"),
]
if winreg:
roots = {
"HKEY_CURRENT_USER": winreg.HKEY_CURRENT_USER,
"HKEY_LOCAL_MACHINE": winreg.HKEY_LOCAL_MACHINE,
}
for root_name, subkey, value_name in reg_paths:
try:
with winreg.OpenKey(roots[root_name], subkey) as key:
value, _ = winreg.QueryValueEx(key, value_name)
v = parse_version(str(value))
if v:
return v, f"registry:{root_name}\\{subkey}"
except Exception:
pass
paths = [
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 path in paths:
if path and os.path.exists(path):
out = run_cmd([path, "--version"])
v = parse_version(out)
if v:
return v, path
return None, ""
def get_version_macos():
paths = [
"/Applications/Google Chrome.app/Contents/MacOS/Google Chrome",
os.path.expanduser("~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome"),
]
for path in paths:
if os.path.exists(path):
out = run_cmd([path, "--version"])
v = parse_version(out)
if v:
return v, path
return None, ""
def get_version_linux():
cmds = [
["google-chrome", "--version"],
["google-chrome-stable", "--version"],
["/usr/bin/google-chrome", "--version"],
["/usr/bin/google-chrome-stable", "--version"],
["chromium-browser", "--version"],
["chromium", "--version"],
]
for cmd in cmds:
exe = cmd[0]
if os.path.isabs(exe) and not os.path.exists(exe):
continue
out = run_cmd(cmd)
v = parse_version(out)
if v:
return v, " ".join(cmd)
return None, ""
def main():
system = platform.system().lower()
if system == "windows":
version, source = get_version_windows()
elif system == "darwin":
version, source = get_version_macos()
else:
version, source = get_version_linux()
if not version:
print("UNKNOWN - Google Chrome version not found")
sys.exit(2)
installed = version_to_str(version)
fixed = version_to_str(PATCHED_FLOOR)
if version < PATCHED_FLOOR:
print(f"VULNERABLE - Installed Chrome {installed} from {source}; fixed floor is {fixed}")
sys.exit(1)
else:
print(f"PATCHED - Installed Chrome {installed} from {source}; meets/exceeds fixed floor {fixed}")
sys.exit(0)
if __name__ == "__main__":
main()
If you remember one thing.
149.0.7827.53, confirm auto-update and restart compliance, and fold stragglers into your next routine browser update wave; for a LOW verdict there is no noisgate mitigation SLA and no noisgate remediation SLA beyond backlog hygiene, so this is normal maintenance work unless you are separately investigating a targeted browser-exploit incident.Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.