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
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.149.0.7827.53 and clean up those pockets during the next routine endpoint maintenance cycle; no SLA applies for this severity.- 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.
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. |
Sources.
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.
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()