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

Insufficient policy enforcement in Workers in Google Chrome prior to 149

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

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.

"Not an internet-to-root bug; it is a chain-helper that matters only after renderer compromise."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Land a separate renderer exploit

The attacker first needs a different Chrome bug that yields code execution or equivalent control inside the renderer process. In practice this is the expensive part of the chain, typically a memory corruption exploit delivered through attacker-controlled web content.
Conditions required:
  • 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
Where this breaks in practice:
  • 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
Detection/coverage: Standard vuln scanners will flag vulnerable Chrome versions, but they cannot validate whether a renderer-compromise prerequisite exists.
STEP 02

Trigger Worker code from a crafted page

Once inside the renderer, the attacker uses JavaScript/HTML that exercises the Worker execution path. The goal is to move execution into the specific policy boundary where enforcement is insufficient.
Conditions required:
  • Renderer is already compromised
  • Worker execution is permitted in the victim browsing context
  • Attacker can still drive script execution in the page
Where this breaks in practice:
  • 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
Detection/coverage: Browser telemetry may show suspicious Worker-heavy activity, but most fleet tools will not map that directly to this CVE.
STEP 03

Bypass same-origin policy inside Workers

The published impact is a same-origin policy bypass via Workers. That gives the attacker a security-boundary weakening primitive inside the browser, useful for reading or altering data flows that should stay origin-confined.
Conditions required:
  • The vulnerable Worker policy path must be reachable
  • The targeted origin data must be present or accessible in-session
Where this breaks in practice:
  • 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
Detection/coverage: No reliable network signature; this is mostly detectable through browser crash/telemetry correlation or post-incident forensic reconstruction.
STEP 04

Abuse the victim's authenticated web session

If the user is logged into a sensitive SaaS or internal web app, the attacker can try to leverage the SOP bypass to tamper with or exfiltrate session-scoped data. The business impact depends heavily on what tabs, sessions, and origins the user already has open.
Conditions required:
  • 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
Where this breaks in practice:
  • 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
Detection/coverage: EDR may only see the precursor exploit or browser instability, not the SOP bypass itself.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo evidence of active exploitation in the reviewed sources; CISA ADP enrichment on the CVE record shows Exploitation: none and Automatable: no via CIRCL.
KEV statusNot listed in the CISA Known Exploited Vulnerabilities Catalog.
Public PoC availabilityNo 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.
EPSS0.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 vectorCVSS: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 versionsGoogle 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 versionsChrome 149.0.7827.53 on Linux and 149.0.7827.53/54 on Windows/macOS in Google's stable-channel release: Chrome Releases.
Exposure realityThis 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 timelinePublished on 2026-06-04 in the CVE/NVD data; the fixing stable-channel release was posted 2026-06-02: CIRCL, Chrome Releases.
ReporterReported by VEZEKA on 2026-04-19 according to Google's release notes entry for CVE-2026-11197: Chrome Releases.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to LOW (3.8/10)

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.

HIGH Requires prior renderer compromise; this is explicit in the published CVE description
MEDIUM No public exploit / no in-the-wild use in reviewed sources as of 2026-06-06
MEDIUM Impact can still be meaningful for high-value authenticated browser sessions

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.

05 · Compensating Control

What to do — in priority order.

  1. 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.
  2. 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.
  3. 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.53 and clean up those pockets during the next routine endpoint maintenance cycle; no SLA applies for this severity.
  4. 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.
What doesn't work
  • 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.
06 · Verification

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.

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

If you remember one thing.

TL;DR
Monday morning, do not treat CVE-2026-11197 like an out-of-band fleet fire. Query your browser inventory for Chrome versions below 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

  1. Google Chrome stable channel update for Desktop (149.0.7827.53/54)
  2. Chromium issue 504073872
  3. GitHub Advisory Database: GHSA-549m-hfh8-j433
  4. CIRCL Vulnerability Lookup: CVE-2026-11197
  5. CISA Known Exploited Vulnerabilities Catalog
  6. FIRST EPSS model documentation
  7. CVE Program portal
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.