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

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

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

This is a spare key left inside the car, but only after the thief already got into the garage

CVE-2026-11140 is an out-of-bounds read in Chrome's Chromecast code path that can leak process memory after a malicious page has already achieved renderer-process compromise. The user-supplied description and Chrome's published release context place affected builds at versions before 149.0.7827.53, with the fixing stable release shipping as 149.0.7827.53 for Linux and 149.0.7827.53/54 for Windows and macOS on June 2, 2026.

Google's MEDIUM 6.5 baseline is directionally fair in a vacuum, but for enterprise prioritization the decisive fact is that this is not an initial-access bug. The attacker must already have popped the renderer, which means the real-world exploit chain needs another browser flaw first; that prerequisite sharply narrows exposure, turns this into a post-compromise info leak, and keeps it out of the same patch queue as direct RCE, sandbox escape, or KEV-listed Chrome bugs.

"This is a chain helper, not an enterprise fire drill: it needs a renderer compromise first."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Land the victim on attacker-controlled HTML

The practical delivery tool is a malicious HTML/JavaScript landing page opened in vulnerable Chrome. This gets the attacker to the browser, but by itself does nothing useful here because CVE-2026-11140 is not directly reachable as a standalone remote leak from normal web content.
Conditions required:
  • Victim browses to attacker-controlled content
  • Chrome version is older than the June 2, 2026 fixed build
  • Relevant Chromecast code is present in the target browser build
Where this breaks in practice:
  • Requires user interaction (UI:R)
  • Phishing, malvertising, or drive-by delivery still has to beat enterprise filtering and user behavior
  • This step only positions the attacker; it does not trigger material impact alone
Detection/coverage: Email gateways, secure web gateways, browser isolation, and DNS filtering can all break this delivery stage; vuln scanners generally cannot validate exploitability from the network.
STEP 02

Compromise the renderer with a separate bug

The weaponized tool at this stage is a separate renderer exploit chain; CVE-2026-11140 explicitly assumes the renderer is already compromised. In practice that means another memory-corruption or logic flaw must first give code execution inside Chrome's sandboxed renderer process.
Conditions required:
  • Attacker has a working renderer compromise for the victim's build
  • Exploit survives modern browser mitigations and site isolation
  • Victim reaches the exploit path before browser update
Where this breaks in practice:
  • This is the biggest downward pressure on severity: the bug is post-initial-exploit inside the browser
  • Usable renderer exploits are expensive and short-lived
  • Exploit developers usually prefer chaining leaks that are more deterministic or already known-good
Detection/coverage: EDR visibility into in-browser renderer exploitation is imperfect; exploit prevention, browser sandboxing, and isolation matter more than classic signature scanning.
STEP 03

Trigger the Chromecast out-of-bounds read

With renderer control, the attacker uses a crafted HTML page plus in-process renderer primitives to exercise the vulnerable Chromecast path and read beyond intended memory bounds. The result is an information disclosure primitive, not code execution and not a sandbox escape on its own.
Conditions required:
  • Renderer process is already under attacker control
  • The specific Chromecast code path is reachable in that session
  • Memory layout yields data worth leaking
Where this breaks in practice:
  • Component-specific trigger surface reduces universality
  • Out-of-bounds reads are often noisy and less deterministic than a targeted arbitrary read
  • Leaked data may be low-value or insufficient for a follow-on stage
Detection/coverage: No reliable network signature. Host coverage is mostly indirect: browser crash telemetry, exploit protection events, and anomaly signals around the original renderer compromise.
STEP 04

Use leaked memory to stabilize or extend the chain

The attacker tool here is a multi-stage browser exploit chain that consumes leaked pointers, tokens, or adjacent process data to defeat mitigations or inform a second bug. This is where CVE-2026-11140 matters operationally: it can make another exploit more reliable, but it usually does not deliver business impact by itself.
Conditions required:
  • Leaked memory contains useful secrets or addresses
  • Attacker has a second-stage objective such as sandbox escape, credential theft, or persistence
  • Chain execution stays stable across target population
Where this breaks in practice:
  • Information disclosure alone rarely closes the objective
  • Blast radius is limited to the browsing context unless paired with another flaw
  • Enterprise browsers restart often and auto-update aggressively, which shortens chain half-life
Detection/coverage: Detection usually comes from the companion bug or post-exploitation behavior, not from this leak primitive itself.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public evidence of active exploitation found in the sources reviewed, and not listed in CISA KEV as of this assessment.
Proof-of-concept availabilityNo public GitHub or researcher PoC surfaced in primary-source-adjacent references reviewed. The Chromium issue is referenced as 501659253 but appears restricted.
EPSS0.00047 from the user-supplied intel block; percentile was not independently verified from a primary EPSS record during this assessment.
KEV statusNo — absent from the CISA Known Exploited Vulnerabilities Catalog.
CVSS vector reality checkCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N captures the confidentiality impact, but it understates the real friction because the description itself requires a pre-compromised renderer.
Affected versionsChrome builds before 149.0.7827.53 are affected per the CVE record aggregation; Google shipped fixes in the Chrome 149 stable release on June 2, 2026.
Fixed versions149.0.7827.53 (Linux) and 149.0.7827.53/54 (Windows/macOS) per Google's stable channel release note. Chromium-based browsers may inherit the bug but ship fixes on their own cadence.
Scanning / exposure dataShodan/Censys-style internet exposure counts are not meaningful here because this is a client-side browser vulnerability, not an externally exposed service listening on a socket.
Disclosure timelineCVE metadata shows publication on 2026-06-04; Google announced the fixed stable build on 2026-06-02.
Reporter / discovererPublic reporting attribution was not exposed in the release note entry for this medium-severity bug. The reference set points to a restricted Chromium issue rather than a named external researcher.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to LOW (3.4/10)

The single biggest driver is the renderer-compromise prerequisite: an attacker must already be executing inside Chrome's sandbox before this bug becomes useful. That turns CVE-2026-11140 from a frontline browser intrusion risk into a narrow post-compromise leak primitive with limited standalone blast radius.

HIGH Renderer-compromise prerequisite materially reduces standalone enterprise risk
MEDIUM Public exploit and researcher attribution visibility is limited by restricted issue details

Why this verdict

  • Major downgrade for attacker position: this is not unauthenticated remote code execution from the open web; it requires an attacker who already compromised the renderer process, which implies a prior successful browser exploit stage.
  • Population narrowing: while Chrome is everywhere, only the subset of victims who are both unpatched *and* hit by a working renderer exploit chain are realistically exposed, which crushes broad enterprise exploitability.
  • Impact is leak-only: the bug discloses memory and can help a chain, but by itself it does not grant integrity impact, persistence, or sandbox escape; no KEV listing and a tiny EPSS further argue against high urgency.

Why not higher?

There is no evidence in the reviewed sources of active exploitation, no public PoC surfaced, and the attacker does not get initial code execution from this flaw alone. The need for a preceding renderer compromise is compounding friction, not a footnote — it is the whole severity story.

Why not lower?

It still lives in a massively deployed browser and can leak high-value process memory once chained, which is useful to real exploit developers. Browser exploit chains are exactly where memory disclosure bugs earn their keep, so this should remain in backlog hygiene rather than being ignored outright.

05 · Compensating Control

What to do — in priority order.

  1. Enforce browser auto-update — Push managed Chrome/Chromium update policy so endpoints converge on the fixed build without waiting for user action. For a LOW verdict there is no SLA here; treat it as backlog hygiene and fold into the next normal endpoint policy cycle.
  2. Prefer browser isolation for high-risk users — Use remote browser isolation or hardened browsing tiers for admins, finance, and targeted users so renderer exploitation lands in a disposable session instead of the endpoint. For a LOW verdict there is no mitigation SLA; deploy as part of broader control maturity, not as an emergency exception.
  3. Block unmanaged browsers — Use EDR, MDM, or application control to limit unsupported Chromium forks and portable browsers that may lag Chrome's fix cadence. For a LOW verdict there is no SLA; clean this up in the next software governance sweep.
What doesn't work
  • A WAF does not meaningfully help; this is a client-side browser issue triggered by attacker-controlled web content after the page is rendered.
  • Perimeter network ACLs do not solve a renderer-chain bug in a user browser; if the user can browse out, the trigger can arrive.
  • A routine credential reset is not a direct mitigation because the flaw is about in-process memory disclosure, not account takeover by itself.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your software inventory runner, not from an auditor workstation. Invoke it with python3 chrome_cve_2026_11140_check.py on Windows, macOS, or Linux; standard user rights are usually enough because it only reads executable version metadata and common install paths.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# CVE-2026-11140 local exposure check
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN

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

TARGET = (149, 0, 7827, 53)

def parse_ver(s):
    m = re.search(r'(\d+)\.(\d+)\.(\d+)\.(\d+)', s)
    if not m:
        return None
    return tuple(int(x) for x in m.groups())

def cmp_ver(a, b):
    return (a > b) - (a < b)

def run(cmd):
    try:
        p = subprocess.run(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True, timeout=10)
        if p.returncode == 0:
            return p.stdout.strip() or p.stderr.strip()
    except Exception:
        return None
    return None

def windows_candidates():
    paths = []
    for base in [os.environ.get('ProgramFiles'), os.environ.get('ProgramFiles(x86)'), os.environ.get('LocalAppData')]:
        if not base:
            continue
        paths.extend([
            os.path.join(base, 'Google', 'Chrome', 'Application', 'chrome.exe'),
            os.path.join(base, 'Chromium', 'Application', 'chrome.exe'),
            os.path.join(base, 'Microsoft', 'Edge', 'Application', 'msedge.exe'),
        ])
    return [p for p in paths if p and os.path.exists(p)]

def windows_file_version(path):
    ps = [
        'powershell', '-NoProfile', '-Command',
        f"(Get-Item '{path.replace("'", "''")}').VersionInfo.ProductVersion"
    ]
    return run(ps)

def unix_candidates():
    names = ['google-chrome', 'google-chrome-stable', 'chromium', 'chromium-browser', 'microsoft-edge', 'microsoft-edge-stable']
    found = []
    for n in names:
        p = shutil.which(n)
        if p:
            found.append(p)
    extra = [
        '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
        '/Applications/Chromium.app/Contents/MacOS/Chromium'
    ]
    for p in extra:
        if os.path.exists(p):
            found.append(p)
    return list(dict.fromkeys(found))

def binary_version(path):
    out = run([path, '--version'])
    if out:
        return out
    return None

def assess_versions(version_map):
    assessed = []
    vulnerable = []
    patched = []
    for name, verstr in version_map.items():
        ver = parse_ver(verstr)
        if not ver:
            continue
        assessed.append((name, verstr, ver))
        if cmp_ver(ver, TARGET) < 0:
            vulnerable.append((name, verstr))
        else:
            patched.append((name, verstr))
    return assessed, vulnerable, patched

def main():
    system = platform.system().lower()
    versions = {}

    if 'windows' in system:
        for path in windows_candidates():
            ver = windows_file_version(path)
            if ver:
                versions[path] = ver
    else:
        for path in unix_candidates():
            ver = binary_version(path)
            if ver:
                versions[path] = ver

    assessed, vulnerable, patched = assess_versions(versions)

    if vulnerable:
        print('VULNERABLE')
        for name, ver in vulnerable:
            print(f'{name}: {ver}')
        sys.exit(1)

    if patched:
        print('PATCHED')
        for name, ver in patched:
            print(f'{name}: {ver}')
        sys.exit(0)

    print('UNKNOWN')
    print('No supported Chrome/Chromium executable found or version could not be parsed.')
    sys.exit(2)

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

If you remember one thing.

TL;DR
Monday morning: do not burn emergency patch capital on this one unless it is bundled into your normal browser rollup. For a LOW verdict there is no noisgate mitigation SLA and no noisgate remediation SLA — treat CVE-2026-11140 as backlog hygiene, validate your managed fleet is taking Chrome 149+, and fold any stragglers into the next routine browser update cycle while you reserve fast-lane attention for direct browser RCEs, sandbox escapes, and anything with KEV or active exploitation evidence.

Sources

  1. Google Chrome Releases - Stable Channel Update for Desktop (June 2, 2026)
  2. Chromium issue reference 501659253
  3. Vulnerability-Lookup entry for CVE-2026-11140
  4. CISA Known Exploited Vulnerabilities Catalog
  5. FIRST EPSS API documentation
  6. Canadian Centre for Cyber Security advisory AV26-544
  7. SecurityWeek coverage of Chrome 149 security fixes
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.