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

Out of bounds read in WebRTC in Google Chrome prior to 149

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

This is a peephole in the browser wall, not a front-door breach

CVE-2026-11096 is an out-of-bounds read in WebRTC in Google Chrome. Per the vendor description, Chrome versions prior to 149.0.7827.53 are affected, and a remote attacker can trigger the bug with a crafted HTML page to read memory they should not see. The disclosure date is 2026-06-04; the fixed desktop build was already appearing in Google's release channels by 2026-05-29.

The vendor's MEDIUM / 6.5 is basically right, and if anything a little generous for enterprise prioritization. Yes, Chrome is everywhere, but the real-world chain still needs user interaction, lands inside a sandboxed browser renderer, and the primitive described is information disclosure, not code execution or sandbox escape. That sharply limits blast radius compared with the Chrome bugs that actually burn incident-response time.

"Ubiquitous target, but this is still a user-driven renderer memory leak, not a turnkey enterprise compromise."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Lure the user to attacker HTML

The attacker needs a victim to open a page that drives vulnerable WebRTC code paths. The practical weapon here is just a crafted HTML/JavaScript page using browser-native WebRTC APIs; no authentication is required, but the user must browse to it.
Conditions required:
  • Target is running Chrome earlier than 149.0.7827.53
  • Victim visits attacker-controlled or attacker-influenced content
  • WebRTC is available and not disabled by policy
Where this breaks in practice:
  • This is UI:R; no click, no bug
  • Browser filtering, URL rewriting, and safe-browsing controls reduce successful delivery
  • Many enterprises patch Chrome quickly through auto-update or managed rings
Detection/coverage: Traditional network scanners will not find this; this is a client-side exposure problem. Coverage is mostly via asset inventory, browser version telemetry, EDR/browser extension telemetry, and web proxy logs.
STEP 02

Trigger the WebRTC OOB read

The page exercises the vulnerable WebRTC path to cause an out-of-bounds read. That gives the attacker a memory disclosure primitive in the renderer context rather than arbitrary native execution.
Conditions required:
  • Bug is reachable in the victim's platform/build
  • Attacker can reliably shape input to hit the faulty read
Where this breaks in practice:
  • OOB reads are often noisy and brittle across versions and architectures
  • Memory layout variability reduces reliability at scale
  • Modern browser hardening limits the value of a raw read primitive
Detection/coverage: Exploit-specific detection is weak unless you have telemetry from the browser process. Crashes, renderer instability, or unusual WebRTC API invocation bursts may show up in EDR or browser crash reporting.
STEP 03

Harvest renderer-process data

The attacker then scrapes whatever sensitive data is present in reachable process memory: page content, tokens, fragments of cross-origin material, or other transient browser data. The likely weaponized tooling is a custom JavaScript memory-harvesting harness built around the info-leak primitive.
Conditions required:
  • Useful secrets must actually be resident in the affected process memory
  • The victim must be concurrently handling valuable web sessions or data
Where this breaks in practice:
  • Chrome's site isolation and process separation reduce what is co-resident
  • The CVE text promises only potentially sensitive information, not deterministic secret theft
  • Leak value depends heavily on victim browsing state at the moment of exploitation
Detection/coverage: There is no dependable signature for 'memory was read.' Detection is indirect: suspicious follow-on session use, anomalous browser behavior, and identity telemetry for stolen web tokens.
STEP 04

Monetize leaked session material

If useful tokens or data are recovered, the attacker pivots into account access, session hijack, or targeted follow-on phishing. This is where business impact appears, but it is conditional on what the renderer happened to expose, not guaranteed by the CVE itself.
Conditions required:
  • Recovered data must be valid and still usable
  • Stolen sessions must not be strongly bound to device or MFA state
Where this breaks in practice:
  • Session binding, short-lived tokens, and re-authentication kill a lot of the value
  • Identity monitoring can catch impossible-travel or abnormal session reuse
  • This is a weak standalone enterprise attack unless chained with something else
Detection/coverage: Best detection is on the identity side: reused cookies, token abuse, new geo/device session anomalies, and unusual SaaS activity after suspicious browsing events.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public evidence of active exploitation found. Not listed in CISA KEV, and the vendor material surfaced here does not mention exploitation in the wild.
KEV statusNot KEV-listed as of 2026-06-05 review against the CISA KEV catalog.
PoC availabilityNo public PoC located in primary-source review. Chromium issue details appear restricted pending patch adoption, which is normal for Chrome security bugs.
EPSS0.00032 from the user-supplied intel. That is extremely low and supports treating this as a routine browser patch, not an emergency hunt.
CVSS and what it really meansCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N scores the bug as a clean remote info leak, but the key limiter is UI:R plus the fact that the stated outcome is confidentiality only.
Affected versionsGoogle states Chrome prior to 149.0.7827.53 is affected. In practice that means the enterprise risk pool is unmanaged laggards, broken auto-update rings, VDI gold images, and test systems.
Fixed versionFixed in Chrome 149.0.7827.53. Google's release material shows 149.0.7827.53/.54 entering desktop stable channels on 2026-05-29, and Chrome for Testing shows 149.0.7827.53 as stable by 2026-06-05.
Exposure / scanning realityThis is not an internet-facing service flaw, so Shodan/Censys/GreyNoise-style edge telemetry is mostly irrelevant. Exposure is measured by fleet version coverage, not open ports; the upside for defenders is that managed browser telemetry usually answers that quickly.
Disclosure date2026-06-04 in the supplied intel and Chrome CNA publication stream.
Researcher attributionNot yet clearly exposed in public primary sources reviewed. Chrome commonly withholds detailed bug metadata until enough users are patched.
04 · The Call

noisgate verdict.

Final Verdict
= UNCHANGED to MEDIUM (4.8/10)

The decisive factor is that this bug is a user-driven browser info leak with impact apparently constrained to renderer-process memory, not a reliable remote takeover primitive. Chrome's ubiquity keeps it out of LOW, but the lack of active exploitation, lack of a public weaponized PoC, and limited technical impact keep it firmly out of HIGH.

HIGH Exploit preconditions and attacker-position assessment
MEDIUM Ultimate data-exposure impact in real enterprise browsing scenarios

Why this verdict

  • User interaction drags this down: the attacker still needs a victim to browse to malicious content, which makes this a delivery problem before it becomes a memory-leak problem.
  • Renderer-only blast radius matters: the published effect is information disclosure from process memory, not code execution or a sandbox escape, so the practical damage is narrower than the CVSS confidentiality score suggests in isolation.
  • No exploitation signal: no KEV listing, no public in-the-wild note, and the supplied EPSS 0.00032 all argue against panic patching.
  • But Chrome ubiquity keeps it at MEDIUM: even modest browser bugs deserve attention because nearly every enterprise user runs the target and the exploit surface is hostile web content.

Why not higher?

A HIGH rating would need a stronger amplifier: active exploitation, a public PoC with good reliability, clear cross-origin secret exfiltration at scale, or a second-stage path to code execution or sandbox escape. We do not have that here. This is a single-browser-tab style primitive, not a dependable enterprise intrusion accelerant by itself.

Why not lower?

A LOW rating would understate the combination of massive deployment footprint and remote triggerability through normal browsing. Even without code execution, browser memory disclosures can still expose tokens or sensitive page data, and that is too real to throw into backlog hygiene.

05 · Compensating Control

What to do — in priority order.

  1. Enforce browser auto-update — Make sure Chrome stable rings are actually moving and that broken update channels, pinned versions, VDI images, and kiosk builds are surfaced. For a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but auto-update validation is the fastest way to collapse exposure without heroic effort.
  2. Inventory lagging Chrome builds — Pull version telemetry from EDR, MDM, SCCM/Intune, browser cloud management, or package inventory and isolate anything below 149.0.7827.53. There is no mitigation SLA — go straight to the 365-day remediation window, so the job is disciplined cleanup of unmanaged and stranded browsers.
  3. Reduce unneeded WebRTC exposure where feasible — If parts of the fleet do not need browser-based calling, conferencing, or RTC workflows, disable or restrict WebRTC via enterprise policy in those segments. This is a compensating control only; for MEDIUM there is no mitigation SLA — go straight to the 365-day remediation window.
  4. Watch for identity-side fallout — Because the realistic harm here is stolen session material, tune SaaS and IdP analytics for anomalous session reuse, device changes, and suspicious browser-origin activity after risky browsing. That helps catch the part of the chain that actually matters to the business.
What doesn't work
  • A network vulnerability scanner will not meaningfully help; this is a client-side browser versioning problem, not an exposed server daemon.
  • A perimeter WAF does not solve endpoint browsing to arbitrary internet content, especially when the malicious page is delivered over normal HTTPS.
  • MFA alone does not fully neutralize session-token theft if the attacker gets reusable browser session material.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your endpoint management tooling. Invoke it with python3 chrome_cve_2026_11096_check.py on macOS/Linux or py chrome_cve_2026_11096_check.py on Windows; standard user rights are usually enough, though registry and application path visibility are better with local admin.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# CVE-2026-11096 Chrome version checker
# 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, capture_output=True, text=True, timeout=10)
        out = (p.stdout or '') + '\n' + (p.stderr or '')
        return out.strip()
    except Exception:
        return ''


def find_windows():
    candidates = [
        os.path.join(os.environ.get('ProgramFiles', ''), 'Google', 'Chrome', 'Application', 'chrome.exe'),
        os.path.join(os.environ.get('ProgramFiles(x86)', ''), 'Google', 'Chrome', 'Application', 'chrome.exe'),
        os.path.join(os.environ.get('LocalAppData', ''), 'Google', 'Chrome', 'Application', 'chrome.exe'),
    ]
    for path in candidates:
        if path and os.path.exists(path):
            out = run_cmd(['powershell', '-NoProfile', '-Command', f"(Get-Item '{path}').VersionInfo.ProductVersion"]) 
            ver = parse_version(out)
            if ver:
                return path, ver
    try:
        import winreg
        keys = [
            r'SOFTWARE\Google\Chrome\BLBeacon',
            r'SOFTWARE\WOW6432Node\Google\Chrome\BLBeacon',
        ]
        for hive in (winreg.HKEY_CURRENT_USER, winreg.HKEY_LOCAL_MACHINE):
            for key in keys:
                try:
                    k = winreg.OpenKey(hive, key)
                    version, _ = winreg.QueryValueEx(k, 'version')
                    ver = parse_version(version)
                    if ver:
                        return f'{hive}:{key}', ver
                except OSError:
                    pass
    except Exception:
        pass
    return None, None


def find_macos():
    candidates = [
        '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
        os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
    ]
    for path in candidates:
        if os.path.exists(path):
            out = run_cmd([path, '--version'])
            ver = parse_version(out)
            if ver:
                return path, ver
    return None, None


def find_linux():
    cmds = ['google-chrome', 'google-chrome-stable', 'chromium-browser', 'chromium']
    for cmd in cmds:
        out = run_cmd([cmd, '--version'])
        ver = parse_version(out)
        if ver:
            return cmd, ver
    return None, None


def main():
    system = platform.system().lower()
    if 'windows' in system:
        source, ver = find_windows()
    elif 'darwin' in system:
        source, ver = find_macos()
    else:
        source, ver = find_linux()

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

    if cmp_version(ver, FIXED) < 0:
        print(f'VULNERABLE - found {ver[0]}.{ver[1]}.{ver[2]}.{ver[3]} from {source}; fixed is 149.0.7827.53+')
        sys.exit(1)
    else:
        print(f'PATCHED - found {ver[0]}.{ver[1]}.{ver[2]}.{ver[3]} from {source}; fixed is 149.0.7827.53+')
        sys.exit(0)


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

If you remember one thing.

TL;DR
Monday morning, treat this as a fleet hygiene browser patch, not a crisis hunt: confirm Chrome auto-update is working, identify any endpoints still below 149.0.7827.53, and clean up pinned or stranded builds first. For a MEDIUM verdict there is noisgate mitigation SLAno mitigation SLA — go straight to the 365-day remediation window — and the noisgate remediation SLA is ≤365 days; in practice, because this is Chrome, most teams should fold it into the next managed browser rollout rather than let it sit for quarters.

Sources

  1. Google Chrome Releases - Early Stable Update for Desktop (149.0.7827.53/.54)
  2. Google Chrome Releases homepage
  3. Chrome for Testing availability - stable 149.0.7827.53
  4. CIRCL Vulnerability-Lookup search results for Chrome June 2026 CVEs
  5. CIRCL Vulnerability-Lookup Chrome search
  6. FIRST EPSS overview
  7. FIRST EPSS API documentation
  8. CISA Known Exploited Vulnerabilities Catalog
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.