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

Insufficient policy enforcement in ServiceWorker in Google Chrome prior to 149

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

This is a peephole in Chrome’s same-origin wall, not a master key

CVE-2026-11206 is a ServiceWorker policy-bypass flaw in Google Chrome that lets a remote attacker leak cross-origin data by getting a user to load a crafted HTML page. The affected range is Chrome before 149.0.7827.53; Google’s June 2, 2026 stable release moved Linux to 149.0.7827.53 and Windows/macOS to 149.0.7827.53/54.

Google calling this MEDIUM is basically right, and if anything slightly generous for enterprise patch triage. The bug matters because Chrome is everywhere, but the exploit chain is still user-driven, confidentiality-only, and browser-contained—no code execution, no sandbox escape, no privileged foothold, and no evidence here of a public exploit wave.

"A real browser bug, but still a lure-the-user data leak—not the kind of Chrome issue that should blow up your queue"
02 · The Attack Path

4 steps from start to impact.

STEP 01

Lure the user to attacker content

The attacker needs a user on a vulnerable Chrome build to open a malicious web page. The weaponized tool here is just a crafted HTML/JavaScript page that exercises the ServiceWorker bug; there is no indication of a pre-auth server-side foothold or local privilege requirement.
Conditions required:
  • Victim is running Chrome older than 149.0.7827.53
  • Victim loads attacker-controlled web content
  • JavaScript and ServiceWorker behavior are available in the browsing context
Where this breaks in practice:
  • Requires user interaction; this is not wormable or self-propagating
  • Enterprise web filtering, safe browsing, or email URL defense can reduce reach
  • Many fleets auto-update Chrome quickly, shrinking the window
Detection/coverage: Traditional network vuln scanners will miss this. Detection is mostly software inventory/version compliance plus web/email telemetry showing users hitting suspicious domains.
STEP 02

Register or abuse ServiceWorker state

The crafted page attempts to drive Chrome’s ServiceWorker handling into the vulnerable path where policy enforcement is insufficient. In practical terms, the attacker is trying to get browser-managed background logic to act on data boundaries it should have enforced.
Conditions required:
  • Target site/browser state aligns with the vulnerable code path
  • ServiceWorker execution is not blocked by enterprise policy or browsing mode
Where this breaks in practice:
  • ServiceWorker exploitation is usually stateful and implementation-specific, not as point-and-shoot as a memory-corruption RCE
  • Private browsing modes, restrictive browser policies, or cleared profile state may reduce reliability
Detection/coverage: No dependable signature-based scanner coverage is expected. Browser telemetry, EDR browser process monitoring, and URL telemetry help more than CVE scanners here.
STEP 03

Bypass same-origin-style checks

If the bug triggers, the attacker can cause Chrome to mishandle cross-origin policy boundaries and expose data that should remain isolated. Chromium’s own security design assumes these boundaries block one site from reading another, so this step is the actual security failure.
Conditions required:
  • The targeted data is accessible in the victim’s browser session
  • The vulnerable policy path is reached successfully
Where this breaks in practice:
  • Blast radius is limited to what that user can access in that browser session
  • Site Isolation and browser process boundaries reduce some classes of cross-site abuse, even if this bug weakens policy enforcement
Detection/coverage: Hard to detect directly. You are more likely to notice it through suspicious browser traffic patterns, anomalous exfil destinations, or user/session abuse on downstream SaaS platforms.
STEP 04

Exfiltrate data off-box

The final step is ordinary web exfiltration: the malicious page sends leaked cross-origin data back to attacker infrastructure. The weaponized tooling is again minimal—standard browser networking from attacker JavaScript and collection endpoints.
Conditions required:
  • Outbound access to attacker-controlled infrastructure
  • Useful target data present in session context
Where this breaks in practice:
  • This is confidentiality-only impact; the attacker does not get code execution or host control from this CVE alone
  • Network egress controls, secure web gateways, and DLP can catch or block some exfil attempts
Detection/coverage: Proxy logs, SWG telemetry, DNS, and SaaS anomaly monitoring are better bets than host vulnerability probes.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo confirmed exploitation found in the sources reviewed. CISA KEV does not list this CVE.
Proof-of-concept availabilityNo public PoC located in reviewed sources. Chromium issue 505427216 exists but is marked with permissions required, which usually means details are intentionally restricted while fixes propagate.
EPSS0.00036 (*user-supplied*), which is effectively near the floor and argues against panic prioritization. I did not independently verify the percentile from FIRST during this run.
KEV statusNot KEV-listed as of this assessment; reviewed against the CISA Known Exploited Vulnerabilities Catalog.
CVSS vector meaningCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N means remote delivery with no privileges, but user interaction is required and impact is data disclosure only.
Affected versionsGoogle Chrome prior to 149.0.7827.53 per NVD/vendor advisory. For enterprise reality, that means any lagging desktop fleet still below the June 2, 2026 stable train.
Fixed versionsPatched in Chrome 149.0.7827.53 for Linux and 149.0.7827.53/54 for Windows/macOS. Chrome for Testing also shows stable availability at 149.0.7827.53.
Exposure and scanning realityThis is a client-side browser flaw, so Shodan/Censys/FOFA are largely irrelevant. Exposure is measured by endpoint/browser inventory, not internet-facing banners.
Disclosure timelineCVE published 2026-06-04; Chrome stable desktop release carrying the fix landed 2026-06-02.
Reporting researcherReported by David Bors and Catalin Iovita in Chrome’s 2026 release archive.
04 · The Call

noisgate verdict.

Final Verdict
= UNCHANGED to MEDIUM (5.8/10)

The decisive factor is user interaction: the attacker must get a victim onto a malicious page, which sharply reduces exploit reach compared with a passive drive-by RCE or an unauthenticated server bug. On top of that, the impact is confidentiality-only inside the browser session, with no evidence of active exploitation or public weaponization pushing this above routine browser patch priority.

HIGH Affected version and fix version mapping
MEDIUM Exploit practicality without the restricted Chromium bug details
HIGH Severity bucket placement for enterprise patch triage

Why this verdict

  • Start from vendor 6.5 MEDIUM because Chrome is massively deployed and the bug is remotely triggerable with no attacker privileges
  • Downward pressure: user interaction is mandatory; this requires phishing, malvertising, or a malicious site visit, which kills wormability and cuts reachable population versus passive exploitation
  • Downward pressure: impact is confidentiality-only; there is no RCE, no sandbox escape, and no host-level persistence from this CVE alone
  • Downward pressure: blast radius is session-bounded; the attacker only gets what the victim’s browser context can expose, not broad enterprise control
  • No upward pressure from threat intel; no KEV listing, no public PoC found, and EPSS is extremely low

Why not higher?

It is not HIGH because the chain lacks the things that justify queue-jumping in a 10,000-host environment: there is no pre-auth server exposure, no code execution, and no observed exploitation. A browser data leak with UI:R is a real risk, but it is still a post-click problem with a narrower operational payoff than the Chrome bugs that turn into sandbox escapes or full compromise.

Why not lower?

It is not LOW because Chrome is a universal enterprise attack surface and the weakness can expose cross-origin data, which can absolutely matter if the victim is logged into sensitive SaaS apps. Even without code execution, a same-origin boundary failure in a mainstream browser deserves more than backlog-only treatment.

05 · Compensating Control

What to do — in priority order.

  1. Enforce browser auto-update and restart compliance — Make sure managed Chrome channels are allowed to update and that users are actually restarting into the fixed build. For a MEDIUM noisgate verdict there is no mitigation SLA, so use this as a normal hardening control and go straight to the remediation window rather than running an emergency exception campaign.
  2. Tighten risky web-path controls — Reduce the chance of step 1 by pushing suspicious URLs through secure web gateway inspection, browser isolation, and phishing controls. Again, there is no mitigation SLA for MEDIUM here, so do this as part of steady-state browsing risk reduction, not as a fire drill.
  3. Prioritize high-value user cohorts — If you cannot confirm patch uptake everywhere, verify admins, finance, executives, developers, and help desk first because their browser sessions carry the most valuable SaaS context. This is the practical blast-radius reducer while the normal remediation process catches up.
  4. Hunt for stale Chrome versions — Use endpoint inventory, EDR software data, or management tooling to find hosts below 149.0.7827.53. For this MEDIUM case, focus on coverage and cleanup instead of emergency containment.
What doesn't work
  • A network perimeter firewall does not fix a client-side same-origin policy failure inside the browser; the exploit rides over normal web traffic.
  • Server patching on your internal apps does not remediate this CVE; the vulnerable component is the user’s Chrome client.
  • Assuming Chrome auto-update alone solved it is not enough if endpoints are offline, pinned to old versions, or users have not restarted into the patched build.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your endpoint management/EDR script runner. Invoke it with python3 check_cve_2026_11206.py on macOS/Linux or py -3 check_cve_2026_11206.py on Windows; no admin rights are required for the common install paths and registry reads used here.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# CVE-2026-11206 Chrome version check
# Outputs: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

import os
import platform
import re
import shutil
import subprocess
import sys

THRESHOLD = "149.0.7827.53"


def parse_version(v):
    parts = re.findall(r"\d+", v or "")
    return tuple(int(x) for x in parts)


def cmp_version(a, b):
    aa = list(parse_version(a))
    bb = list(parse_version(b))
    m = max(len(aa), len(bb))
    aa += [0] * (m - len(aa))
    bb += [0] * (m - len(bb))
    if aa < bb:
        return -1
    if aa > bb:
        return 1
    return 0


def add_result(results, path, version):
    if version:
        results.append((path, version.strip()))


def get_windows_versions():
    results = []
    try:
        import winreg
    except Exception:
        winreg = None

    reg_paths = [
        r"SOFTWARE\Google\Chrome\BLBeacon",
        r"SOFTWARE\WOW6432Node\Google\Chrome\BLBeacon",
    ]
    if winreg:
        for hive in (winreg.HKEY_CURRENT_USER, winreg.HKEY_LOCAL_MACHINE):
            for reg_path in reg_paths:
                try:
                    with winreg.OpenKey(hive, reg_path) as key:
                        version, _ = winreg.QueryValueEx(key, "version")
                        add_result(results, f"registry:{reg_path}", version)
                except OSError:
                    pass

    exe_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 exe in exe_paths:
        if exe and os.path.exists(exe):
            try:
                out = subprocess.check_output([
                    "powershell",
                    "-NoProfile",
                    "-Command",
                    f"(Get-Item '{exe}').VersionInfo.ProductVersion"
                ], stderr=subprocess.DEVNULL, text=True, timeout=10)
                add_result(results, exe, out)
            except Exception:
                pass
    return results


def get_macos_versions():
    results = []
    apps = [
        "/Applications/Google Chrome.app/Contents/MacOS/Google Chrome",
        os.path.expanduser("~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome"),
    ]
    for app in apps:
        if os.path.exists(app):
            try:
                out = subprocess.check_output([app, "--version"], stderr=subprocess.DEVNULL, text=True, timeout=10)
                m = re.search(r"(\d+\.\d+\.\d+\.\d+)", out)
                if m:
                    add_result(results, app, m.group(1))
            except Exception:
                pass
    return results


def get_linux_versions():
    results = []
    candidates = [
        "google-chrome",
        "google-chrome-stable",
        "chromium",
        "chromium-browser",
    ]
    for cmd in candidates:
        path = shutil.which(cmd)
        if path:
            try:
                out = subprocess.check_output([path, "--version"], stderr=subprocess.DEVNULL, text=True, timeout=10)
                m = re.search(r"(\d+\.\d+\.\d+\.\d+)", out)
                if m:
                    add_result(results, path, m.group(1))
            except Exception:
                pass
    return results


def main():
    system = platform.system().lower()
    results = []

    if "windows" in system:
        results = get_windows_versions()
    elif "darwin" in system:
        results = get_macos_versions()
    elif "linux" in system:
        results = get_linux_versions()
    else:
        print("UNKNOWN - unsupported platform")
        sys.exit(2)

    # de-duplicate by version/path pairs
    uniq = []
    seen = set()
    for item in results:
        if item not in seen:
            uniq.append(item)
            seen.add(item)
    results = uniq

    if not results:
        print("UNKNOWN - Chrome not found")
        sys.exit(2)

    vulnerable = []
    patched = []
    unknown = []

    for path, version in results:
        if not parse_version(version):
            unknown.append((path, version))
        elif cmp_version(version, THRESHOLD) < 0:
            vulnerable.append((path, version))
        else:
            patched.append((path, version))

    if vulnerable:
        detail = "; ".join([f"{p}={v}" for p, v in vulnerable])
        print(f"VULNERABLE - found Chrome below {THRESHOLD}: {detail}")
        sys.exit(1)

    if patched and not vulnerable:
        detail = "; ".join([f"{p}={v}" for p, v in patched])
        print(f"PATCHED - found Chrome at or above {THRESHOLD}: {detail}")
        sys.exit(0)

    detail = "; ".join([f"{p}={v}" for p, v in unknown]) if unknown else "version parse failed"
    print(f"UNKNOWN - {detail}")
    sys.exit(2)


if __name__ == "__main__":
    main()
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning: do not treat this like an emergency Chrome zero-day. Use endpoint inventory to find Chrome versions below 149.0.7827.53, verify auto-update/restart compliance, and absorb this into your next normal browser rollout; for a MEDIUM verdict there is no noisgate mitigation SLA — go straight to the 365-day remediation window. That said, because browser risk decays quickly when fleets stay current, you should still clean up laggards in your routine cycle now and complete patch adoption well before the noisgate remediation SLA outer limit of ≤365 days.

Sources

  1. Chrome stable desktop release (June 2, 2026)
  2. NVD record for CVE-2026-11206
  3. Chromium issue 505427216
  4. CISA Known Exploited Vulnerabilities Catalog
  5. FIRST EPSS API documentation
  6. Chromium Site Isolation security documentation
  7. Chrome for Testing availability
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.