← Back to Feed CACHED · 2026-06-06 14:50:24 · CACHE_KEY CVE-2026-11176
CVE-2026-11176 · CWE-346 · Disclosed 2026-06-04

Google Chrome Media cross-origin data leak via crafted HTML page

ASSESSED — NOISGATE
Vendor
—
—
—
Reassessed
—
—
—
Verdict: —
Do you agree?
01 · The Real Story

This is a peephole drilled through the same-origin wall, not a front door kicked off the hinges

CVE-2026-11176 is a Chrome Media implementation flaw that can let a malicious webpage read data it should not get from another origin. The affected population is broad in install base but narrow in versioning: Chrome desktop builds prior to 149.0.7827.53 on Linux and the June 2026 149.0.7827.53/54 stable rollout on Windows and macOS are in scope; downstream Chromium-based browsers are exposed until they rebase or backport the fix.

Google called this MEDIUM (6.5), and that is basically right. The bug is remote and confidentiality-impacting, but it still depends on *user interaction*, a crafted page, and a browser-only blast radius; there is no public sign here of a clean pre-auth worm path, server-side reachability, or code execution chain that would justify a jump into the urgent buckets.

"Real bug, real data exposure, but it still needs user click-through and stays in the browser lane."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Deliver a crafted page

The attacker needs the victim to open attacker-controlled HTML/JS that exercises the vulnerable Media code path. This is the weaponized stage here: a custom browser PoC delivered by phishing, malvertising, a compromised site, or an ad slot.
Conditions required:
  • Unauthenticated remote attacker
  • Victim uses vulnerable Chrome build
  • Victim browses to attacker-controlled or attacker-influenced content
Where this breaks in practice:
  • UI:R is real friction; no user, no bug
  • Email gateway, web filtering, Safe Browsing, ad blocking, and user behavior all suppress reachability
  • There is no widely-circulating named exploit kit or public PoC for this CVE as of 2026-06-06
Detection/coverage: Weak direct detection. You usually see delivery telemetry in secure web gateway, email, DNS, or browser isolation logs rather than a clean signature for the exploit itself.
STEP 02

Trigger the Media flaw

Once the page loads, the attacker abuses the Media implementation bug to break expected cross-origin isolation and pull data from another origin. Technically, this is a same-origin boundary failure with confidentiality impact rather than a takeover primitive.
Conditions required:
  • Target page hits the vulnerable Media code path
  • Cross-origin target data is reachable in the victim browser context
Where this breaks in practice:
  • Modern Chrome isolation features reduce the number of cross-origin cases that yield useful content
  • A lot of enterprise SaaS content is additionally protected by CSP, anti-framing, token binding patterns, or app-layer checks
  • Bug details are still partly restricted, which usually slows copycat weaponization
Detection/coverage: No reliable network IOC by default. Browser crash telemetry is not a good signal because this is a data leak class issue, not necessarily a crashy memory corruption event.
STEP 03

Harvest user-scoped data

If successful, the attacker gets data exposed in the victim's browser session for the targeted origin. In practice that means the blast radius is usually the currently logged-in user profile, not the host, domain, or enterprise at large.
Conditions required:
  • Victim is authenticated to a useful target web app or has accessible cross-origin content worth stealing
Where this breaks in practice:
  • Impact is bounded to what the user can access in-browser
  • No integrity or availability gain is described
  • EDR will not usually see host compromise because there may be none
Detection/coverage: Look for suspicious follow-on account activity in SaaS audit logs, session anomalies, and unusual browser-driven data access rather than endpoint malware artifacts.
STEP 04

Operationalize stolen data

The attacker turns the leaked content into account abuse, recon, or targeted follow-on phishing. This is where the business harm happens, but it requires the earlier user-driven browser exploit to succeed first.
Conditions required:
  • Stolen data has credential, token, or sensitive-content value
  • Attacker can use the data before sessions expire or controls revoke access
Where this breaks in practice:
  • Short-lived tokens, conditional access, and app-layer anomaly detection reduce monetization
  • The exploit by itself does not provide code execution or persistence
Detection/coverage: SaaS logs, IdP sign-in telemetry, and impossible-travel/session anomaly detections are more useful than host IOC hunting.
03 · Compensating Control

1
Force browser auto-update compliance — Use GPO/MDM/endpoint management to verify Chrome auto-update is enabled and relaunch suppression is not leaving users stranded on stale versions. For a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but Chrome is low-friction to update, so use routine compliance reporting rather than emergency change control.
2
Quarantine pinned or frozen browser rings — Identify VDI pools, kiosk images, legacy app compatibility groups, and hosts with disabled Omaha/Google Update or pinned milestones. These are the systems that turn a normally self-healing browser issue into long-tail exposure; clear them inside the 365-day remediation window and preferably much sooner as part of normal desktop hygiene.
3
Tighten malicious-content delivery controls — Lean on secure web gateway, DNS filtering, Safe Browsing, mail-link protection, and browser isolation for untrusted destinations. These controls do not fix the bug, but they directly attack the highest-friction prerequisite: getting a victim to render attacker HTML in the first place.
4
Watch high-value SaaS accounts for odd browser-driven access — Because the likely harm is stolen cross-origin web content, bias monitoring toward IdP and SaaS audit logs for privileged users, executives, finance, HR, and admins. This is not a patch substitute, but it is the right detective control for a confidentiality-only browser issue during the remediation window.
What doesn't work
  • Server-side WAF tuning does not fix a client-side browser implementation flaw; the bug executes in the victim browser after content is rendered.
  • Perimeter vulnerability scanners will not meaningfully measure exposure because Chrome on endpoints is not an internet-facing service you can census from the outside.
  • MFA by itself does not prevent browser-session data leakage once the victim is already authenticated to the target web app in that browser context.
04 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo confirmed active exploitation in the sources reviewed; not listed by CISA KEV as of 2026-06-06.
Proof-of-concept availabilityNo public GitHub/Exploit-DB PoC found in quick checks for CVE-2026-11176; that is an inference from current public search results, not a guarantee none exists privately.
EPSS0.00014 (~0.014%), which is extremely low and argues against emergency reprioritization on exploit-likelihood grounds alone.
KEV statusNot KEV-listed; no CISA due date applies.
CVSS vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N = remotely reachable *if* the victim opens attacker content; confidentiality-only impact, no integrity or availability component.
Affected versionsChrome desktop before 149.0.7827.53; Google/Cyber Centre note the June stable rollout as 149.0.7827.53 for Linux and 149.0.7827.53/54 for Windows/macOS.
Fixed versionsPatch baseline is 149.0.7827.53 (Linux) and 149.0.7827.53/54 (Windows/macOS). Chromium downstreams need either a rebase to the fixed milestone or an explicit vendor backport.
Scanning / exposure dataShodan/Censys/FOFA are basically the wrong lens here: this is a client-side browser bug, not a bannered server service. Internet-wide scanner counts do not tell you your exposed population; your EDR/MDM browser-version inventory does.
Disclosure timelineChrome stable fix shipped 2026-06-02; CVE record published 2026-06-04.
Reporting researcher / orgReported by Google on 2026-04-14 in Chromium issue 502371717.

Sources.

  1. Google Chrome Releases: Stable Channel Update for Desktop (June 2, 2026)
  2. Chromium issue 502371717
  3. Canadian Centre for Cyber Security AV26-544
  4. SecurityWeek coverage of Chrome 149 release
  5. PCWorld coverage of Chrome 149 fixes
  6. CISA Known Exploited Vulnerabilities Catalog
  7. FIRST EPSS project
  8. Chrome Releases index
05 · The Call

Final Verdict
= UNCHANGED to MEDIUM (5.8/10)

Why this verdict

  • Start at Google's 6.5 MEDIUM baseline because the primitive is a real same-origin/confidentiality failure in a massively deployed browser.
  • Subtract for UI:R and client-side reachability: the attacker is unauthenticated remote, but the prerequisite implies user click/view behavior and content delivery success; that is materially less reliable than exploiting an exposed server on your edge.
  • Subtract for narrow blast radius: even if exploited, the effect is user-profile/browser-session scoped data leakage, not domain-wide compromise, no host code execution, and no built-in persistence.
  • Do not subtract all the way to LOW because Chrome is ubiquitous and cross-origin leaks can expose authenticated SaaS data that matters in real enterprises, especially for privileged web admins and finance/legal users.

Why not higher?

There is no evidence here of active exploitation, KEV status, public weaponization, or an easy chain to RCE. The attacker still needs a victim in the loop, and the stated impact is confidentiality leakage inside the browser, which is serious but not in the same operational class as a pre-auth server RCE or browser sandbox escape.

Why not lower?

Calling this LOW would understate the ubiquity of Chrome and the fact that a same-origin break can expose genuinely sensitive web application data. Even without code execution, a browser-session data leak against the right user can become a real incident.

06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your EDR/remote-exec tool, not from an auditor workstation. Invoke it with python3 check_chrome_cve_2026_11176.py on macOS/Linux or py check_chrome_cve_2026_11176.py on Windows; no admin rights are normally required.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# check_chrome_cve_2026_11176.py
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

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

FIXED = (149, 0, 7827, 53)
VERSION_RE = re.compile(r'(\d+)\.(\d+)\.(\d+)\.(\d+)')


def parse_version(text):
    m = VERSION_RE.search(text or '')
    if not m:
        return None
    return tuple(int(x) for x in m.groups())


def version_ge(a, b):
    return a >= b


def run_cmd(cmd):
    try:
        p = subprocess.run(cmd, capture_output=True, text=True, timeout=10)
        out = (p.stdout or '') + '\n' + (p.stderr or '')
        return out.strip()
    except Exception:
        return ''


def candidate_commands():
    system = platform.system().lower()
    cmds = []

    if system == 'windows':
        local = os.environ.get('LOCALAPPDATA', '')
        program_files = os.environ.get('ProgramFiles', '')
        program_files_x86 = os.environ.get('ProgramFiles(x86)', '')
        paths = [
            os.path.join(program_files, 'Google', 'Chrome', 'Application', 'chrome.exe'),
            os.path.join(program_files_x86, 'Google', 'Chrome', 'Application', 'chrome.exe'),
            os.path.join(local, 'Google', 'Chrome', 'Application', 'chrome.exe'),
        ]
        for p in paths:
            if p and os.path.exists(p):
                cmds.append([p, '--version'])
        # Registry fallback via PowerShell if chrome.exe is not in standard paths
        cmds.append(['powershell', '-NoProfile', '-Command', "(Get-ItemProperty 'HKLM:\\Software\\Google\\Chrome\\BLBeacon' -ErrorAction SilentlyContinue).version"])
        cmds.append(['powershell', '-NoProfile', '-Command', "(Get-ItemProperty 'HKCU:\\Software\\Google\\Chrome\\BLBeacon' -ErrorAction SilentlyContinue).version"])

    elif system == 'darwin':
        mac_path = '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'
        if os.path.exists(mac_path):
            cmds.append([mac_path, '--version'])
        for name in ['google-chrome', 'chrome', 'chromium', 'chromium-browser']:
            found = shutil.which(name)
            if found:
                cmds.append([found, '--version'])

    else:
        for name in ['google-chrome', 'google-chrome-stable', 'chromium', 'chromium-browser', 'chrome']:
            found = shutil.which(name)
            if found:
                cmds.append([found, '--version'])
        # Common package-manager fallbacks
        cmds.append(['bash', '-lc', "dpkg-query -W -f='${Version}\n' google-chrome-stable 2>/dev/null || true"])
        cmds.append(['bash', '-lc', "rpm -q --qf '%{VERSION}-%{RELEASE}\n' google-chrome-stable 2>/dev/null || true"])

    return cmds


def main():
    seen = []
    for cmd in candidate_commands():
        out = run_cmd(cmd)
        if not out:
            continue
        ver = parse_version(out)
        if ver:
            seen.append((cmd[0], ver, out.strip()))

    if not seen:
        print('UNKNOWN: Could not determine installed Chrome version')
        sys.exit(2)

    # Choose the highest discovered version if multiple are installed
    seen.sort(key=lambda x: x[1], reverse=True)
    source, ver, raw = seen[0]

    if version_ge(ver, FIXED):
        print(f'PATCHED: detected {ver[0]}.{ver[1]}.{ver[2]}.{ver[3]} via {source}')
        sys.exit(0)
    else:
        print(f'VULNERABLE: detected {ver[0]}.{ver[1]}.{ver[2]}.{ver[3]} via {source}; fixed is 149.0.7827.53 or later')
        sys.exit(1)


if __name__ == '__main__':
    main()