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

Use after free in WebRTC in Google Chrome prior to 149

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

This is a burglar getting into the building lobby, not the server room

The authoritative public record appears to be CVE-2026-10903, not CVE-2026-11003; as of 2026-06-05, NVD and Google both describe a use-after-free in WebRTC affecting Google Chrome before 149.0.7827.53 on Linux and before 149.0.7827.53/.54 on Windows and macOS. The bug is reachable by getting a user to render attacker-controlled web content, which can drive memory corruption and achieve arbitrary code execution inside Chrome's sandboxed renderer.

Google's HIGH / 8.8 label is defensible in Chrome's own taxonomy because they rate sandboxed code execution as High. For enterprise patch triage, though, that overstates the operational blast radius: this is not a one-bug host takeover, it still needs user interaction, and there is no KEV listing, no vendor-stated in-the-wild exploitation, and a very low user-supplied EPSS value. Treat it as an important browser update, not an all-hands emergency.

"This is a real browser RCE bug, but sandbox-only impact and no exploitation signal keep it out of fire-drill territory."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Land the victim on attacker-controlled content

The attacker needs the target to load a malicious page, malvertising slot, or embedded content that can exercise the vulnerable WebRTC code paths. In practice this is classic browser exploitation delivery: phishing, watering hole, ad-tech abuse, or compromised legitimate sites.
Conditions required:
  • Unauthenticated remote attacker
  • Victim uses affected Chrome version
  • Victim visits attacker-controlled or attacker-influenced page
Where this breaks in practice:
  • Requires user interaction (UI:R), not a passively exposed network service
  • Enterprise DNS filtering, SWG, and browser isolation can cut off many delivery paths
  • Some desktops block or heavily restrict risky browsing categories
Detection/coverage: Network scanners do not meaningfully detect this. Coverage is mostly web filtering telemetry, phishing telemetry, and browser version inventory.
STEP 02

Trigger the WebRTC memory corruption

Once the page is loaded, exploit code abuses WebRTC state transitions or object lifetime handling to hit a use-after-free in the renderer process. This is memory-unsafe bug territory: reliability matters, and exploitability is workload-, platform-, and build-dependent.
Conditions required:
  • WebRTC code path reachable from page content
  • Exploit chain tailored to the target Chrome build and platform
Where this breaks in practice:
  • Modern Chrome hardening raises exploit engineering cost
  • Restricted bug details mean public weaponization is not obvious yet
  • Many memory corruption attempts manifest first as renderer crashes, not stable code execution
Detection/coverage: Browser crash spikes and EDR child-process anomalies may surface failed attempts, but there is no reliable signature for the vulnerability itself.
STEP 03

Execute code inside the renderer sandbox

Successful exploitation yields code execution in a sandboxed Chrome process. That is serious, but it is still inside the browser isolation boundary rather than native execution with user privileges on the host.
Conditions required:
  • Exploit achieves reliable control of instruction flow
  • Renderer sandbox remains the immediate execution context
Where this breaks in practice:
  • Sandbox containment sharply limits immediate host impact
  • Site isolation and process separation reduce cross-origin blast radius
  • EDR and application control have a better chance once behavior escapes normal renderer patterns
Detection/coverage: EDR may catch suspicious post-exploitation actions from chrome renderer processes, but pure in-sandbox execution can be quiet.
STEP 04

Convert browser foothold into useful impact

To turn this into a workstation compromise, the attacker usually needs a second bug such as a sandbox escape, privilege escalation, or high-value data already accessible from the compromised browser context. Without that second step, impact is typically constrained to origin/session abuse, limited data theft, or use as one stage in a chain.
Conditions required:
  • Additional exploit or accessible high-value browser-resident data
  • Target's browsing context contains something worth stealing or abusing
Where this breaks in practice:
  • No public evidence this bug ships with a paired escape
  • Credential protections, HTTP-only cookies, and origin boundaries reduce simple smash-and-grab outcomes
  • Enterprise browsers often run with sync, extension, and policy controls that limit abuse paths
Detection/coverage: Post-exploitation detection is stronger here: token misuse, anomalous browser child processes, LSASS access, lateral movement, or suspicious downloads.
03 · Intelligence Metadata

The supporting signals.

Record sanity checkThe public authoritative record reviewed is CVE-2026-10903. I found no matching authoritative public record for CVE-2026-11003 as of 2026-06-05, so this looks like a likely transposition typo.
In-the-wild statusNo public exploitation evidence found in reviewed primary sources. Google did not flag active exploitation in the release post, and CISA KEV does not list it.
Proof-of-concept availabilityNo public PoC located in reviewed sources. The Chromium issue link is access-restricted, which usually delays casual copycat weaponization.
EPSSUser-supplied EPSS: 0.00071; that is a very low absolute exploitation probability signal. Percentile was not independently verified from FIRST in the reviewed sources.
KEV statusNot listed in CISA's Known Exploited Vulnerabilities catalog as of 2026-06-05.
CVSS and what it really meansCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H maps to an internet-deliverable bug that still needs a click/view. The big caveat is the impact is sandboxed code execution, not automatic host takeover.
Affected versionsChrome before 149.0.7827.53 on Linux and before 149.0.7827.53/.54 on Windows and macOS.
Fixed versionsUpdate to 149.0.7827.53+ on Linux and 149.0.7827.53/.54+ on Windows/macOS. I found no primary-source distro backport statement for this specific CVE in the reviewed material.
Scanning / exposure realityThis is client software, not an internet-facing service. Shodan/Censys/FOFA-style exposure counts are not a useful measure here, and external vuln scanners generally miss browser laggards unless they ingest endpoint inventory or EDR/MDM telemetry.
Disclosure / reporterPublicly disclosed 2026-06-04 via the CVE/NVD record; Google's release post says it was reported on 2026-04-17 by c6eed09fc8b174b0f3eebedcceb1e792.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to MEDIUM (6.3/10)

The decisive factor is sandbox-only execution: this bug compromises a renderer, not the endpoint, unless the attacker also has a second-stage escape or a very specific data target in-browser. That sharply narrows the practical blast radius compared with what the raw vendor CVSS suggests.

HIGH Metadata accuracy for the authoritative public record being **CVE-2026-10903**
MEDIUM Operational severity downgrade based on sandbox containment and lack of exploitation evidence
MEDIUM Exposure assessment for enterprise fleets where Chrome is widespread but usually auto-updates quickly

Why this verdict

  • -1.4 for sandbox-only impact: Google's own severity guidance treats renderer code execution as High, but for enterprise patch prioritization a sandboxed foothold is materially less dangerous than direct host-native RCE.
  • -0.6 for required victim participation: the attacker must get a user onto malicious content; this is not a remotely reachable daemon or appliance bug.
  • -0.5 for weak exploitation signal: no KEV entry, no public vendor claim of active exploitation, and the supplied EPSS is extremely low.

Why not higher?

There is no public evidence of active exploitation, no KEV listing, and no indication this CVE includes a sandbox escape. If you strip away exploit-chain assumptions, the delivered impact is a contained browser-process compromise rather than immediate endpoint compromise.

Why not lower?

This is still a real memory corruption bug in a ubiquitous browser component with attacker-controlled web content as the delivery vehicle. If you run a large fleet, someone in it will hit hostile web content eventually, and browser bugs are often used as chain starters.

05 · Compensating Control

What to do — in priority order.

  1. Enforce browser auto-update — Use GPO/MDM/enterprise browser policy to ensure Chrome reaches 149.0.7827.53/.54 or later and that users cannot indefinitely defer restarts. For a MEDIUM verdict there is no mitigation SLA — use this as risk reduction while completing patching within 365 days.
  2. Inventory version laggards — Pull Chrome version telemetry from EDR, MDM, or software inventory and identify endpoints stuck below the fixed builds. For a MEDIUM verdict there is no mitigation SLA — focus on cleanup of unmanaged and non-updating exceptions inside the 365-day remediation window.
  3. Isolate risky browsing paths — Apply remote browser isolation, stricter URL filtering, or higher-friction browsing policies for high-risk users such as admins, finance, and executives. This does not replace patching, but for MEDIUM severity it is a sensible compensating layer while you work through the normal remediation cycle.
  4. Hunt for abnormal Chrome child-process behavior — Tune EDR for suspicious process creation, script interpreters, credential access, or unusual network activity launched from chrome renderer trees. There is no MEDIUM mitigation SLA, so treat this as detection hardening while the fleet moves to patched builds within 365 days.
What doesn't work
  • Perimeter vulnerability scanning doesn't help much here because Chrome is client software, not an exposed service.
  • MFA does not prevent memory corruption in the browser engine; it only helps on the account-abuse side after compromise.
  • Generic network IPS signatures are weak coverage because exploit delivery is ordinary web content and the bug is in client-side parsing/runtime behavior.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your EDR/remote execution tool. Invoke it with python3 check_chrome_cve_2026_10903.py; it needs no admin rights for local version checks, but it must run in a user context that can read the Chrome binary paths.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# check_chrome_cve_2026_10903.py
# Detects whether local Google Chrome is vulnerable to CVE-2026-10903
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

import os
import platform
import re
import subprocess
import sys
from shutil import which

FIXED_LINUX = (149, 0, 7827, 53)
FIXED_WIN_MAC = (149, 0, 7827, 53)  # advisory says .53/.54 for Win/Mac; .53 is acceptable floor


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


def run_cmd(cmd):
    try:
        out = subprocess.check_output(cmd, stderr=subprocess.STDOUT, text=True, timeout=10)
        return out.strip()
    except Exception:
        return None


def find_windows_chrome():
    candidates = [
        os.path.join(os.environ.get('ProgramFiles', r'C:\Program Files'), 'Google', 'Chrome', 'Application', 'chrome.exe'),
        os.path.join(os.environ.get('ProgramFiles(x86)', r'C:\Program Files (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):
            return path
    return None


def find_macos_chrome():
    path = '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'
    return path if os.path.exists(path) else None


def find_linux_chrome():
    for name in ['google-chrome', 'google-chrome-stable', 'chrome', 'chromium', 'chromium-browser']:
        p = which(name)
        if p:
            return p
    for path in ['/opt/google/chrome/chrome', '/usr/bin/google-chrome', '/usr/bin/google-chrome-stable']:
        if os.path.exists(path):
            return path
    return None


def get_version_from_binary(path):
    out = run_cmd([path, '--version'])
    return parse_version(out), out


def compare(v, fixed):
    if v is None:
        return None
    return v >= fixed


def main():
    system = platform.system().lower()
    chrome_path = None
    fixed = None

    if 'windows' in system:
        chrome_path = find_windows_chrome()
        fixed = FIXED_WIN_MAC
    elif 'darwin' in system:
        chrome_path = find_macos_chrome()
        fixed = FIXED_WIN_MAC
    elif 'linux' in system:
        chrome_path = find_linux_chrome()
        fixed = FIXED_LINUX
    else:
        print('UNKNOWN: unsupported platform')
        sys.exit(2)

    if not chrome_path:
        print('UNKNOWN: Chrome binary not found')
        sys.exit(2)

    version, raw = get_version_from_binary(chrome_path)
    if version is None:
        print(f'UNKNOWN: unable to parse version from {chrome_path}')
        sys.exit(2)

    is_patched = compare(version, fixed)
    ver_str = '.'.join(str(x) for x in version)
    fixed_str = '.'.join(str(x) for x in fixed)

    if is_patched:
        print(f'PATCHED: detected {ver_str} at {chrome_path} (fixed floor {fixed_str})')
        sys.exit(0)
    else:
        print(f'VULNERABLE: detected {ver_str} at {chrome_path} (needs >= {fixed_str})')
        sys.exit(1)


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

If you remember one thing.

TL;DR
Monday morning, first correct the record to CVE-2026-10903, then pull Chrome version inventory and confirm affected endpoints are below 149.0.7827.53/.54. This is not a drop-everything zero-day response item: under the noisgate mitigation SLA there is no mitigation SLA — go straight to the 365-day remediation window, and under the noisgate remediation SLA you should complete patching within 365 days; operationally, that means verifying auto-update is working now and burning down stuck/non-updating browsers in your normal endpoint hygiene cycle rather than running an emergency campaign.

Sources

  1. Google Chrome Releases - Stable Channel Update for Desktop (June 2, 2026)
  2. NVD record for CVE-2026-10903
  3. Chromium severity guidelines for security issues
  4. Chromium Site Isolation overview
  5. Chromium Security home
  6. CISA Known Exploited Vulnerabilities catalog
  7. FIRST EPSS API documentation
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.