← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
CVE-2026-11174 · CWE-693 · Disclosed 2026-06-04

Inappropriate implementation in Site Isolation in Google Chrome prior to 149

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
01 · The Real Story

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.

"This is a chain-enabler, not an entry point: it matters after renderer compromise, not before."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Land the user on a malicious page

The attacker needs ordinary web reachability first: phishing, malvertising, compromised site, or a lure URL. The page itself is not enough to cash out CVE-2026-11174; it is only the delivery vehicle for a larger browser exploit chain.
Conditions required:
  • Target uses vulnerable Chrome build
  • User visits attacker-controlled or attacker-influenced content
  • Attacker can serve crafted HTML/JS
Where this breaks in practice:
  • User interaction is required
  • Safe Browsing, URL filtering, mail security, and ad blocking reduce reach
  • The bug does not trigger meaningful impact by itself
Detection/coverage: Web proxy, DNS, and email telemetry can catch the lure stage; vulnerability scanners generally cannot.
STEP 02

Compromise the renderer first

This CVE assumes the attacker has already achieved renderer compromise through a separate bug class such as memory corruption, UXSS, or another browser logic flaw. In real-world terms, the attacker needs a distinct exploit to gain code execution or equivalent control inside Chrome's renderer sandbox before this issue matters.
Conditions required:
  • 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
Where this breaks in practice:
  • 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
Detection/coverage: Look for browser crashes, exploit protection hits, renderer process anomalies, and repeated short-lived chrome child process failures.
STEP 03

Abuse Site Isolation policy enforcement

With renderer control in hand, the attacker abuses the Site Isolation weakness to weaken the browser's cross-site compartmentalization. The value of the bug is that it may let a compromised renderer observe or access data from other origins that should have been withheld from that process.
Conditions required:
  • 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
Where this breaks in practice:
  • 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
Detection/coverage: There is little signature-friendly network evidence for the bypass itself; browser forensics and exploit telemetry matter more than perimeter tools.
STEP 04

Read and exfiltrate cross-origin data

If the chain holds, the attacker can extract sensitive information from browser contexts that should have remained isolated. Typical impact is confidentiality loss, not durable host compromise or enterprise-wide lateral movement.
Conditions required:
  • Useful session data is present in the browser
  • Attacker has an exfiltration path from the browser process
  • Victim is logged into applications worth targeting
Where this breaks in practice:
  • 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
Detection/coverage: Monitor suspicious browser egress, abnormal uploads to rare domains, and user reports of odd tab behavior; asset scanners offer no direct coverage.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public exploitation evidence found in the sources reviewed, and not listed in CISA KEV as of 2026-06-06.
Public PoC / exploit codeNo public vendor-linked PoC. Google notes bug details may remain restricted until broad patch uptake, which is typical when exploit chaining is plausible.
EPSS0.00028 — effectively background noise for enterprise prioritization unless paired with another actively exploited Chrome bug.
KEV statusNot in KEV. No forced immediate-action signal from CISA.
CVSS vectorCVSS: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 versionsChrome 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 versionsLinux: 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 realityNot 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.
TimelineEarly 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.
ReporterReported by Google on 2026-04-14 per the Chrome stable bulletin.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to LOW (3.2/10)

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.

HIGH Affected versions and fixed versions
MEDIUM Standalone severity downgrade versus vendor MEDIUM
MEDIUM Absence of public exploitation evidence

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.

05 · Compensating Control

What to do — in priority order.

  1. 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.
  2. 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).
  3. 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.
  4. 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).
What doesn't work
  • 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.
06 · Verification

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.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/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()
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning: do not treat this like an emergency browser fire drill. This is a LOW reassessment because it is valuable mainly after renderer compromise, so there is no noisgate mitigation SLA and no noisgate remediation SLA beyond backlog hygiene; keep Chrome auto-update healthy, verify your fleet is flowing to 149.0.7827.53+, and fold any lagging images, gold builds, and kiosk pools into the next routine browser maintenance cycle rather than burning an out-of-band patch window.

Sources

  1. Chrome Stable Channel Update for Desktop (Chrome 149)
  2. Chrome Early Stable Update for Desktop
  3. Chromium Site Isolation overview
  4. Chromium Security page
  5. CISA Known Exploited Vulnerabilities Catalog
  6. FIRST EPSS API documentation
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.