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

Inappropriate implementation in WebRTC in Google Chrome prior to 149

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

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

CVE-2026-11200 is a WebRTC origin-validation / implementation flaw in Google Chrome that can let a remote attacker leak cross-origin data by getting a user to open a crafted HTML page. The affected range is Chrome versions before 149.0.7827.53; Google’s desktop stable release notes show 149.0.7827.53 for Linux and 149.0.7827.53/54 for Windows and macOS as the fixed train, with an early stable rollout beginning May 29, 2026 and broader stable promotion on June 2, 2026.

Google’s MEDIUM / 6.5 label is broadly fair, but a bit generous for enterprise patch triage once you do the friction audit. This is not RCE, not a sandbox escape, not wormable, and there is no cited in-the-wild exploitation or KEV listing; the attacker still needs the user to browse attacker-controlled content, and the practical blast radius is usually the victim’s active browser session rather than host takeover.

"Real bug, real data leak, but it still needs a victim to land on attacker content and stays inside browser scope"
02 · The Attack Path

4 steps from start to impact.

STEP 01

Host the lure page

The attacker prepares a malicious HTML/JavaScript page that exercises the vulnerable WebRTC behavior described in the Chrome advisory. There is no need for authentication on the target endpoint because the delivery vector is just normal web browsing; the 'tool' here is a custom browser-side script, not a server exploit framework. Reference: Chrome stable advisory.
Conditions required:
  • Victim runs Chrome older than 149.0.7827.53
  • Victim can reach attacker-controlled web content
Where this breaks in practice:
  • No host compromise occurs unless the user actually loads attacker content
  • Email gateways, web filters, Safe Browsing, and user behavior all reduce reach
Detection/coverage: Traditional network scanners will miss this. Detection is mainly version inventory plus URL/web telemetry showing visits to suspicious attacker domains.
STEP 02

Land the victim on attacker content

The attacker must drive the user to the crafted page through phishing, malvertising, chat links, or a compromised site. This is the decisive real-world friction point: exploitation is user-driven client-side execution rather than a direct hit against an enterprise server. No public turnkey offensive kit was identified in the primary references reviewed.
Conditions required:
  • User interaction: open the page or click the link
  • Browser protections or policy do not block the destination
Where this breaks in practice:
  • Requires a lure campaign or preexisting control of a site the victim already visits
  • Modern enterprise controls can suppress low-reputation destinations
Detection/coverage: Email security, SWG, DNS logs, browser history/telemetry, and EDR browser eventing can often show the delivery path even if they cannot prove the bug fired.
STEP 03

Trigger WebRTC cross-origin leakage

Once the page runs, the vulnerable WebRTC implementation can leak cross-origin data that should remain isolated by browser policy. The weaponized component is still in-page JavaScript using WebRTC APIs; there is no evidence here of privilege escalation beyond the browser process. Reference: GHSA-p7mc-g528-g76m.
Conditions required:
  • Specific vulnerable WebRTC code path is reachable in the victim browser build
  • Attacker can induce the browser state needed for the leak
Where this breaks in practice:
  • Impact is confidentiality-only in the disclosed scoring
  • Bug details are restricted, which slows commodity weaponization
Detection/coverage: Signature-based detection is weak unless Google or defenders later publish concrete indicators. Browser/EDR telemetry may only show script execution and WebRTC use, not the leak itself.
STEP 04

Collect stolen session-context data

The attacker exfiltrates whatever cross-origin data the flaw exposes and uses it for follow-on abuse such as token theft, internal-app visibility, or targeted recon. That can matter a lot for a single high-value user, but it is still a narrower blast radius than code execution or sandbox escape.
Conditions required:
  • Victim is simultaneously authenticated to sensitive web apps or has interesting browser state
  • Leaked data is sufficient to be operationally useful
Where this breaks in practice:
  • Exposure quality depends heavily on what the user is logged into at that moment
  • Many sessions are short-lived, scoped, or otherwise less reusable than raw host access
Detection/coverage: Look for suspicious follow-on use of web sessions, unusual app access from new IPs, and account telemetry rather than host crash artifacts.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo active exploitation evidence found in the primary sources reviewed. Google’s June 2, 2026 release notes do not include the usual 'Google is aware that an exploit exists in the wild' language used on true Chrome zero-days.
KEV statusNot listed in CISA KEV based on the KEV catalog reference reviewed; no KEV add date present.
Public PoC availabilityNo widely cited public PoC was found in the vendor advisory, GHSA, or NVD-linked references. The Chromium issue is not publicly detailed from the unauthenticated view, which adds friction.
EPSS0.00013 (0.013%), roughly 2.1st percentile in Vulnerability-Lookup’s EPSS enrichment dated 2026-06-06; GitHub shows 0.032% / 10th percentile, so both sources place it near the floor.
CVSS vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:Nnetwork reachable but user-assisted, with confidentiality impact only and no integrity or availability hit.
Affected versionsGoogle Chrome before 149.0.7827.53 across desktop platforms. NVD enrichment models this as versionEndExcluding 149.0.7827.53 for google:chrome.
Fixed versionsLinux: 149.0.7827.53; Windows/macOS: 149.0.7827.53/54 in the Chrome 149 stable release train. Chrome also seeded the same fixed build to a small percentage of desktop users on 2026-05-29 via early stable.
Scanning / exposure realityNot meaningfully internet-scannable via Shodan/Censys/FOFA. This is a client-side browser flaw, so external search engines cannot reliably quantify exposure; your true exposure is your managed Chrome fleet and any unmanaged BYOD Chrome population.
Disclosure timelineCVE published by the Chrome CNA on 2026-06-04; Chrome stable containing the fix was already promoted on 2026-06-02.
Reporter / provenanceRelease notes attribute it to Google and the linked Chromium issue is 504579798, reported 2026-04-20 in the Chrome stable advisory.
04 · The Call

noisgate verdict.

Final Verdict
= UNCHANGED to MEDIUM (5.8/10)

The decisive factor is attacker delivery friction: this bug only becomes dangerous after a user is steered onto attacker-controlled web content, and the disclosed impact is data leakage inside browser scope, not host compromise. With no KEV listing, no vendor-noted in-the-wild exploitation, and EPSS near the floor, this does not earn the same urgency as remotely triggerable server-side flaws or Chrome RCEs.

HIGH Affected versions and fixed build mapping
MEDIUM Real-world exploitation likelihood
MEDIUM Practical blast radius of leaked browser data

Why this verdict

  • Down from 6.5 because it requires user interaction: the attacker needs the victim to open a crafted page, which implies a lure or a compromised site rather than direct remote reachability into your estate
  • Down because it is post-click and client-side: the exposed population is 'users who browse attacker content on vulnerable Chrome,' not every host with port exposure or every server running the product
  • Down because the technical impact is confidentiality-only: no integrity or availability loss is scored, and nothing in the primary sources indicates sandbox escape or code execution
  • Not lower because Chrome is everywhere: even medium-grade browser bugs matter at enterprise scale when thousands of users carry active sessions to SaaS, admin consoles, and internal apps
  • Not lower because cross-origin leakage can still be operationally useful: session-adjacent browser data can enable targeted follow-on abuse against high-value users even without device takeover

Why not higher?

There is no evidence in the reviewed primary sources of active exploitation, KEV inclusion, wormability, or server-side reachability. The attack chain also depends on victim browsing behavior and yields a narrower outcome than the Chrome bugs that justify HIGH or CRITICAL, such as RCE, sandbox escape, or universal security-boundary bypass.

Why not lower?

This is still a remotely delivered browser security-boundary failure in one of the most widely deployed enterprise applications on the planet. If the right user lands on the right page while authenticated to sensitive web apps, the confidentiality impact can be meaningful enough that this should stay out of the backlog-hygiene bucket.

05 · Compensating Control

What to do — in priority order.

  1. Force browser auto-update compliance — Use Chrome Browser Cloud Management, your endpoint platform, or software deployment tooling to drive endpoints to 149.0.7827.53/54 or later. Because this is a MEDIUM finding there is no mitigation SLA; use this as standard risk reduction while you close devices inside the 365-day remediation window.
  2. Tighten WebRTC IP handling for high-risk groups — Apply the Chrome Enterprise WebRtcIPHandling policy for admin, finance, and exec populations to reduce what WebRTC can expose and over which interfaces. This is not a full fix, but it is a sensible containment step for users with the most valuable browser sessions while patch adoption completes within the 365-day remediation window.
  3. Restrict media capture defaults where business allows — Set DefaultMediaStreamSetting to prompt or deny by default for groups that do not need broad WebRTC/media access. That limits related browser abuse surface and is worth doing as a policy hardening measure even though there is no mitigation SLA for a MEDIUM verdict.
  4. Prioritize unmanaged and long-tail endpoints — The real residual risk is not your mainstream managed fleet; it is kiosks, VDI gold images, infrequently used laptops, contractors, and users outside your normal browser update ring. Hunt those exceptions first so they do not remain vulnerable for most of the remediation window.
What doesn't work
  • A WAF does not meaningfully help because the vulnerable component is the client browser, not your web app perimeter
  • An internet exposure scanner will not tell you whether this is fixed because Chrome desktop versions are not reliably externally enumerable
  • Generic network segmentation does little for the primary exploit step; the attacker only needs the user to browse a malicious page
  • Blocking all WebRTC traffic everywhere is usually too blunt and can break legitimate collaboration apps, while still not substituting for patching
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or via your EDR/management agent on representative hosts. Invoke it with python3 chrome_cve_2026_11200_check.py on macOS/Linux or py chrome_cve_2026_11200_check.py on Windows; no admin rights are required unless your environment restricts reading application paths/registry.

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

import os
import platform
import re
import subprocess
import sys

FIXED = (149, 0, 7827, 53)


def parse_version(text):
    if not text:
        return None
    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_version(a, b):
    return (a > b) - (a < b)


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_windows_version():
    candidates = [
        [r'reg', 'query', r'HKLM\Software\Google\Chrome\BLBeacon', '/v', 'version'],
        [r'reg', 'query', r'HKCU\Software\Google\Chrome\BLBeacon', '/v', 'version'],
        [r'wmic', 'datafile', 'where', r'name="C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe"', 'get', 'Version', '/value'],
        [r'wmic', 'datafile', 'where', r'name="C:\\Program Files (x86)\\Google\\Chrome\\Application\\chrome.exe"', 'get', 'Version', '/value'],
    ]
    for cmd in candidates:
        text = run_cmd(cmd)
        ver = parse_version(text)
        if ver:
            return ver, text
    return None, ''


def get_macos_version():
    candidates = [
        ['/Applications/Google Chrome.app/Contents/MacOS/Google Chrome', '--version'],
        [os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'), '--version'],
        ['/Applications/Google Chrome.app/Contents/Info.plist'],
    ]
    # Binary --version first
    for cmd in candidates[:2]:
        if os.path.exists(cmd[0]):
            text = run_cmd(cmd)
            ver = parse_version(text)
            if ver:
                return ver, text
    # Fallback to defaults read
    plist = '/Applications/Google Chrome.app/Contents/Info.plist'
    if os.path.exists(plist):
        text = run_cmd(['defaults', 'read', '/Applications/Google Chrome.app/Contents/Info', 'CFBundleShortVersionString'])
        ver = parse_version(text)
        if ver:
            return ver, text
    return None, ''


def get_linux_version():
    candidates = [
        ['google-chrome', '--version'],
        ['google-chrome-stable', '--version'],
        ['/opt/google/chrome/chrome', '--version'],
        ['/usr/bin/google-chrome', '--version'],
        ['/usr/bin/google-chrome-stable', '--version'],
    ]
    for cmd in candidates:
        prog = cmd[0]
        if os.path.isabs(prog) and not os.path.exists(prog):
            continue
        text = run_cmd(cmd)
        ver = parse_version(text)
        if ver:
            return ver, text
    return None, ''


def main():
    system = platform.system().lower()
    ver = None
    raw = ''

    if 'windows' in system:
        ver, raw = get_windows_version()
    elif 'darwin' in system:
        ver, raw = get_macos_version()
    elif 'linux' in system:
        ver, raw = get_linux_version()
    else:
        print('UNKNOWN - unsupported platform: {}'.format(platform.system()))
        sys.exit(2)

    if not ver:
        print('UNKNOWN - Google Chrome version not found')
        sys.exit(2)

    if cmp_version(ver, FIXED) < 0:
        print('VULNERABLE - detected Chrome version {}.{}.{}.{} < 149.0.7827.53'.format(*ver))
        sys.exit(1)
    else:
        print('PATCHED - detected Chrome version {}.{}.{}.{} >= 149.0.7827.53'.format(*ver))
        sys.exit(0)


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

If you remember one thing.

TL;DR
Monday morning, treat this as a standard browser patching issue, not an emergency outage driver: verify fleet compliance to 149.0.7827.53/54 or later, sweep unmanaged and stale endpoints first, and apply WebRTC-hardening policies only for high-risk groups that need extra containment. Because this lands at MEDIUM, there is no noisgate mitigation SLA — go straight to the 365-day remediation window under the noisgate remediation SLA; practically, most enterprises should finish this in their normal browser update ring well before June 2, 2027 rather than letting long-tail devices drift.

Sources

  1. Chrome Releases - Stable Channel Update for Desktop (Chrome 149)
  2. Chrome Releases - Early Stable Update for Desktop
  3. GitHub Advisory Database - GHSA-p7mc-g528-g76m
  4. Vulnerability-Lookup - CVE-2026-11200
  5. NVD - CVE-2026-11200
  6. CISA Known Exploited Vulnerabilities Catalog
  7. Chrome Enterprise Policy - WebRtcIPHandling
  8. Chrome Enterprise Policy - DefaultMediaStreamSetting
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.