Like finding a weak fire door inside a vault after the burglar is already through the lobby
CVE-2026-11174 is an insufficient policy enforcement flaw in Chrome's Site Isolation protections. Affected builds are Google Chrome before 149.0.7827.53 on Linux and before 149.0.7827.53/54 on Windows and macOS. In plain English: if an attacker already has control of the renderer process and can get the user onto a crafted page, this bug may let that compromised renderer reach across origin boundaries and expose data that Site Isolation is supposed to keep separated.
Google labeled it MEDIUM (5.3), but in enterprise triage this lands lower. The decisive friction is the prerequisite: the attacker must already have compromised the renderer process. That means this bug is not initial access, not straight drive-by compromise, and not something an external scanner can hit on your perimeter. It is useful in an exploit chain, but weak as a standalone reason to burn emergency patching capacity.
4 steps from start to impact.
Land the user on a malicious page
- Target uses vulnerable Chrome build
- User visits attacker-controlled or attacker-influenced content
- Attacker can serve crafted HTML/JS
- User interaction is required
- Safe Browsing, URL filtering, mail security, and ad blocking reduce reach
- The bug does not trigger meaningful impact by itself
Compromise the renderer first
- A second browser exploit exists and is reliable against the target build
- That exploit reaches renderer control
- Exploit mitigations like sandboxing and memory protections are bypassed or sidestepped enough to gain renderer foothold
- This is the biggest downward pressure: a separate exploit is mandatory
- Exploit reliability drops sharply across browser versions and mitigations
- EDR, browser crash telemetry, and sandbox hardening raise attacker cost
chrome child process failures.Abuse Site Isolation policy enforcement
- Renderer is already attacker-controlled
- Victim session has interesting cross-origin content loaded or reachable
- The target workflow actually places sensitive data behind Site Isolation boundaries
- Chrome Site Isolation exists specifically to defend against this post-compromise case
- Not all target data will be reachable; CORB/CORS and process boundaries still limit exposure
- Blast radius is bounded to browser-resident data, not host takeover
Read and exfiltrate cross-origin data
- Useful session data is present in the browser
- Attacker has an exfiltration path from the browser process
- Victim is logged into applications worth targeting
- Impact is data theft, not direct OS-level code execution
- Browser session scope limits blast radius to the user and what they have open
- Network DLP, CASB, and anomalous egress monitoring may catch bulk exfiltration
The supporting signals.
| In-the-wild status | No public exploitation evidence found in the sources reviewed, and not listed in CISA KEV as of 2026-06-06. |
|---|---|
| Public PoC / exploit code | No public vendor-linked PoC. Google notes bug details may remain restricted until broad patch uptake, which is typical when exploit chaining is plausible. |
| EPSS | 0.00028 — effectively background noise for enterprise prioritization unless paired with another actively exploited Chrome bug. |
| KEV status | Not in KEV. No forced immediate-action signal from CISA. |
| CVSS vector | CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:N/A:N — the vector already hints at reality: high attack complexity, user interaction required, and confidentiality-only impact. |
| Affected versions | Chrome prior to 149.0.7827.53; Google stable notes specify 149.0.7827.53 on Linux and 149.0.7827.53/54 on Windows and macOS as the fixed desktop builds. |
| Fixed versions | Linux: 149.0.7827.53 or later. Windows/macOS: 149.0.7827.53/54 or later. Android 149.0.7827.59 inherits the corresponding desktop fixes unless otherwise noted by Google. |
| Exposure / scanning reality | Not meaningfully internet-scannable. Shodan/Censys/GreyNoise-style edge exposure data is the wrong lens because this is a client-side browser chain flaw, not a remotely fingerprintable server service. |
| Timeline | Early stable shipped 2026-05-29, broad stable desktop promoted 2026-06-02, and your supplied disclosure date is 2026-06-04. That gap matters: patched builds existed before public CVE enrichment stabilized. |
| Reporter | Reported by Google on 2026-04-14 per the Chrome stable bulletin. |
noisgate verdict.
The single factor that drives this down is attacker position: this bug only pays off after renderer compromise. That makes it a post-exploitation browser chain component with narrow standalone utility, not a practical initial-access event for your enterprise.
Why this verdict
- Renderer compromise required: this is the biggest severity haircut; needing a prior browser exploit compounds real-world friction immediately.
- User-driven reachability only: the attacker still needs the target to browse attacker-controlled content, so this is not a server-side, always-on exposure.
- Blast radius is browser-session scoped: impact is cross-origin data exposure inside Chrome, not direct OS takeover or domain-wide compromise.
Why not higher?
Because the prerequisite chain is brutal. Requiring *unauthenticated remote + user interaction + separate renderer compromise* means most real deployments only become vulnerable after another successful exploit already landed. That's a classic chain amplifier, not a top-of-queue patch driver by itself.
Why not lower?
It is still a security-boundary failure in one of the most widely deployed enterprise applications on earth. If paired with an actively exploited renderer bug, the value of this flaw rises fast because it can turn a sandboxed browser foothold into meaningful cross-origin data theft.
What to do — in priority order.
- Enforce browser auto-update — Make sure enterprise policy keeps Chrome updating normally across managed endpoints and VDI images. For a LOW verdict there is no SLA (treat as backlog hygiene), so the right move is to let standard browser rings pull 149.0.7827.53+ rather than trigger emergency change windows.
- Watch for companion Chrome exploits — Track whether a renderer RCE, UXSS, or actively exploited Chrome zero-day emerges against the same release family. This CVE becomes materially more important only when paired with that first-stage exploit; for LOW, handle this in normal threat-monitoring cadence with no SLA (treat as backlog hygiene).
- Reduce risky web content paths — Keep Safe Browsing, web filtering, attachment detonation, and ad/tracker controls enforced to cut down the chance of users reaching exploit delivery pages. These are reasonable hardening measures, but for this LOW issue there is no SLA (treat as backlog hygiene) rather than an urgent mitigation deadline.
- Harden browser telemetry collection — Retain browser crash logs, EDR browser exploit alerts, and suspicious egress telemetry so you can spot the *other* bug this one depends on. Again, this is hygiene work: no SLA (treat as backlog hygiene).
- A perimeter WAF doesn't help; this is a client-side browser flaw, not an inbound web-app bug on your servers.
- Network vulnerability scanning won't tell you much; scanners can inventory Chrome versions, but they cannot safely validate exploitability of a post-renderer Site Isolation bypass.
- MFA doesn't meaningfully reduce exploitation of the bug itself; it helps account abuse after theft, but it does not stop the browser chain.
Crowdsourced verification payload.
Run this on the target endpoint or through your software inventory tooling. Invoke it with python3 check_chrome_cve_2026_11174.py on macOS/Linux or py check_chrome_cve_2026_11174.py on Windows; no admin rights are required if the Chrome binary is in a standard install path.
#!/usr/bin/env python3
# check_chrome_cve_2026_11174.py
# Exit codes:
# 0 = PATCHED
# 1 = VULNERABLE
# 2 = UNKNOWN
import os
import platform
import re
import subprocess
import sys
from shutil import which
TARGET = "149.0.7827.53"
def parse_version(text):
m = re.search(r"(\d+)\.(\d+)\.(\d+)\.(\d+)", text)
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_version(cmd):
try:
p = subprocess.run(cmd, stdout=subprocess.PIPE, stderr=subprocess.STDOUT, text=True, timeout=5)
out = (p.stdout or "").strip()
v = parse_version(out)
return out, v
except Exception:
return "", None
def candidates():
system = platform.system().lower()
cmds = []
if system == "windows":
local = os.environ.get("LOCALAPPDATA", "")
pf = os.environ.get("PROGRAMFILES", "C:\\Program Files")
pfx86 = os.environ.get("PROGRAMFILES(X86)", "C:\\Program Files (x86)")
paths = [
os.path.join(local, "Google", "Chrome", "Application", "chrome.exe"),
os.path.join(pf, "Google", "Chrome", "Application", "chrome.exe"),
os.path.join(pfx86, "Google", "Chrome", "Application", "chrome.exe"),
]
for p in paths:
cmds.append([p, "--version"])
if which("chrome"):
cmds.append([which("chrome"), "--version"])
elif system == "darwin":
paths = [
"/Applications/Google Chrome.app/Contents/MacOS/Google Chrome",
os.path.expanduser("~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome"),
]
for p in paths:
cmds.append([p, "--version"])
for name in ["google-chrome", "chrome", "chromium", "chromium-browser"]:
if which(name):
cmds.append([which(name), "--version"])
else:
for name in ["google-chrome", "google-chrome-stable", "chrome", "chromium", "chromium-browser"]:
if which(name):
cmds.append([which(name), "--version"])
for p in [
"/opt/google/chrome/chrome",
"/usr/bin/google-chrome",
"/usr/bin/google-chrome-stable",
"/snap/bin/chromium",
]:
cmds.append([p, "--version"])
# Deduplicate while preserving order
seen = set()
uniq = []
for cmd in cmds:
key = tuple(cmd)
if key not in seen:
seen.add(key)
uniq.append(cmd)
return uniq
def main():
target_v = parse_version(TARGET)
found = []
for cmd in candidates():
exe = cmd[0]
if not os.path.exists(exe) and which(exe) is None:
continue
raw, ver = run_version(cmd)
if ver:
found.append((exe, raw, ver))
if not found:
print("UNKNOWN - Google Chrome not found in standard paths or version could not be determined")
sys.exit(2)
# Prefer Google Chrome over Chromium where possible
found.sort(key=lambda x: ("google" not in x[0].lower(), x[0]))
exe, raw, ver = found[0]
if cmp_ver(ver, target_v) < 0:
print(f"VULNERABLE - {raw} at {exe} is older than {TARGET}")
sys.exit(1)
else:
print(f"PATCHED - {raw} at {exe} is {TARGET} or newer")
sys.exit(0)
if __name__ == "__main__":
main()
If you remember one thing.
Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.