← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
CVE-2026-11054 · 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 booby-trapped lobby door, not a master key to the whole building

CVE-2026-11054 is a use-after-free in Chrome's WebRTC stack affecting Chrome before 149.0.7827.53; Google shipped fixes as 149.0.7827.53 for Linux and 149.0.7827.53/54 for Windows and macOS. The practical attack is classic browser exploitation: lure a user to attacker-controlled content, trigger the memory bug through WebRTC-capable page logic, and gain arbitrary code execution inside the renderer sandbox.

Google's HIGH 8.8 is technically defensible for exploitability, but it overstates enterprise urgency if you care about *real-world blast radius*. The decisive friction is that the advertised outcome is sandboxed code execution, not a host takeover; the attacker still needs a second bug, a policy weakness, or accessible in-browser data to turn this into major enterprise damage. With no KEV listing, no public exploit evidence, and very low EPSS, this is a broad patching item, not an emergency outage.

"Remote and real, but sandbox-only plus no exploitation evidence keeps this out of the fire-drill lane."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Deliver a malicious page with custom HTML/JS + WebRTC trigger

The attacker needs the victim to load attacker-controlled web content, typically through phishing, malvertising, or compromised legitimate sites. The weaponized component is not a server-side exploit kit in the classic sense; it is a custom browser-side HTML/JavaScript/WebRTC trigger tuned to hit the vulnerable object lifetime edge case.
Conditions required:
  • Victim is running Chrome below 149.0.7827.53
  • Victim loads attacker-controlled or attacker-influenced web content
  • WebRTC-relevant code path is reachable in that browsing session
Where this breaks in practice:
  • Requires user interaction (UI:R) rather than blind internet reachability
  • Enterprise URL filtering, mail security, and browser isolation can reduce successful delivery
  • Exploit reliability for modern browser memory corruption is usually non-trivial
Detection/coverage: Traditional vulnerability scanners do poorly here; this is primarily a version-detection problem via EDR, MDM, or software inventory rather than exploit-signature scanning.
STEP 02

Trigger the WebRTC use-after-free in the renderer

Once the page runs, the exploit attempts to force object lifetime mismanagement in WebRTC and convert a crash into controlled memory corruption. This is the step where a crash-repro becomes an exploit, typically using custom JS/WebRTC heap grooming rather than an off-the-shelf public framework.
Conditions required:
  • Attacker has a working exploit primitive for this specific Chrome build family
  • Target platform behavior matches exploit assumptions closely enough for reliability
Where this breaks in practice:
  • Browser exploit chains are fragile across patch levels, OS variants, and mitigation states
  • No public PoC or exploit kit is currently visible, which usually means more attacker engineering time
Detection/coverage: Crash telemetry, browser instability spikes, and EDR child-process or memory anomaly detections may catch failed attempts, but deterministic exploit detection is weak.
STEP 03

Gain code execution inside the sandboxed renderer

If exploitation succeeds, the attacker gets code execution inside Chrome's sandbox, which matters but is materially less valuable than native user-context execution. Chromium's own security model treats sandboxing and site isolation as real containment layers, so the attacker lands in a constrained post-exploitation box, not directly on the host.
Conditions required:
  • Renderer compromise succeeds
  • Chrome sandbox is operating as intended
Where this breaks in practice:
  • The sandbox limits host impact and blocks this CVE from being a one-bug workstation takeover
  • Site isolation and browser hardening reduce the amount of cross-site and host access available after compromise
Detection/coverage: EDR may see suspicious browser memory behavior or blocked follow-on actions, but many products will only confirm the host is vulnerable by version, not that exploitation occurred.
STEP 04

Chain a second primitive for meaningful host compromise

To turn this into the kind of damage implied by a fire-drill patch, the attacker usually needs a sandbox escape, a separate local privilege escalation, or access to sensitive data already reachable from the browser context. That extra stage is the biggest downward pressure on severity: this CVE alone is not the whole kill chain.
Conditions required:
  • A second exploitable weakness or valuable browser-accessible target exists
  • Defender controls such as EDR, application control, and OS exploit mitigations do not stop the follow-on stage
Where this breaks in practice:
  • Requires additional attacker capability beyond this CVE
  • Modern endpoint controls are more likely to catch the post-renderer step than the initial trigger
Detection/coverage: Follow-on behavior is where defenders have the best chance: suspicious child processes from Chrome, unusual token access, exploit protection events, or browser-to-system breakout attempts.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusAs of 2026-06-05, there is no public evidence of active exploitation and no CISA KEV listing for CVE-2026-11054.
Public PoC availabilityNo credible public GitHub/Exploit-DB PoC was found in current indexed sources. Expect private crash repros or internal testcases to exist, but nothing broadly weaponized is visible.
EPSS0.00071 (~0.071%) per the intel provided; that is *very low* and consistent with a fresh browser bug lacking public exploitation signals.
KEV statusNot listed in CISA KEV; that removes the strongest external urgency trigger.
CVSS vector readoutCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H means remote and low-complexity once the victim opens hostile content, but it still depends on user interaction and does not claim sandbox escape.
Affected versionsChrome prior to 149.0.7827.53; Google and the Canadian Cyber Centre describe the fixed desktop train as 149.0.7827.53/54 (Windows/macOS) and 149.0.7827.53 (Linux).
Fixed versionsTreat 149.0.7827.53 or later as the minimum safe floor across fleet reporting, with Windows/macOS sometimes surfacing .54 in inventory.
Exposure / scanning realityThis is an endpoint browser issue, so Shodan/Censys/FOFA-style internet exposure counts are the wrong lens. The real exposure driver is Chrome's massive enterprise footprint, not public-service discoverability.
Disclosure date2026-06-04.
Researcher / reporting contextA specific external reporter is not publicly named in the sources reviewed for this CVE. More broadly, Chromium states that around 70% of its serious bugs are memory safety issues and about half of those are use-after-free bugs.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to MEDIUM (6.6/10)

The single biggest severity reducer is impact confinement to the renderer sandbox. This is still a remotely reachable browser memory corruption bug, but without evidence of a paired sandbox escape or in-the-wild exploitation, the enterprise consequence is usually *potential foothold inside Chrome*, not *instant workstation loss*.

HIGH Affected-version and fixed-version mapping
MEDIUM Absence of public PoC / exploitation evidence
MEDIUM Severity downgrade from vendor HIGH to noisgate MEDIUM

Why this verdict

  • Sandbox-only outcome cuts the blast radius: the disclosed impact is code execution *inside Chrome's sandbox*, which is materially less severe than a one-bug endpoint takeover.
  • User interaction is mandatory: the attacker needs the victim to browse hostile content, so this is drive-by capable but not wormable or service-exploitable.
  • No KEV and near-floor EPSS reduce immediate operational risk: there is no public sign of broad weaponization yet, and the provided EPSS of 0.00071 is extremely low.
  • Ubiquity keeps it from dropping lower: Chrome is everywhere, so even a sandboxed renderer RCE deserves disciplined fleet remediation.

Why not higher?

It is not higher because this CVE, as disclosed, stops at sandboxed execution. For a CRITICAL or even strong HIGH call, I would want active exploitation, KEV listing, or evidence that the bug reliably chains to sandbox escape or host compromise in common enterprise builds.

Why not lower?

It is not lower because browsers are a massively exposed client attack surface and a malicious page is a realistic delivery path. Remote, no-auth, low-complexity memory corruption in Chrome still matters at scale, even when the sandbox prevents us from calling it an emergency.

05 · Compensating Control

What to do — in priority order.

  1. Force browser auto-update compliance — Use GPO, MDM, or your endpoint management stack to enforce Chrome version drift limits and report any endpoint below 149.0.7827.53. For a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but browser software should still ride your next managed update cycle rather than wait for annual cleanup.
  2. Prioritize high-risk user cohorts — Front-load patch verification for users who browse untrusted content all day: help desk, HR, recruiters, executives, finance, researchers, and developers. There is no mitigation SLA here, so focus on shrinking exposure through your normal rollout waves and complete remediation comfortably inside the 365-day window.
  3. Use browser isolation where already deployed — If you already run remote browser isolation, VDI, or hardened browsing containers for risky workflows, keep those users there until fleet version compliance is confirmed. This does not replace patching, but it lowers the value of a renderer compromise while you execute the normal MEDIUM-severity patch plan.
  4. Tune endpoint detection for browser breakout behavior — Hunt for suspicious child processes from chrome.exe, abnormal browser memory protections, exploit-block events, and unusual credential or token access immediately after browser sessions. This is not a formal mitigation deadline item for MEDIUM, but it is the best backstop if someone privately weaponizes the bug before your rollout finishes.
What doesn't work
  • A WAF does not help; this is a client-side browser bug triggered by hostile page content after the user loads it.
  • Perimeter internet scanning does not help; vulnerable Chrome versions live on endpoints, not on discoverable public services.
  • Generic server patch cadence dashboards are misleading here; you need endpoint software inventory, not server vuln counts.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your EDR/remote execution tooling. Invoke it with python3 check_chrome_cve_2026_11054.py on macOS/Linux or py check_chrome_cve_2026_11054.py on Windows; no admin rights are normally required, but access to the installed Chrome binary or app bundle metadata is needed.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# check_chrome_cve_2026_11054.py
# Purpose: Determine whether local Google Chrome version is vulnerable to CVE-2026-11054
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

import os
import platform
import re
import subprocess
import sys
from pathlib import Path

MIN_SAFE = (149, 0, 7827, 53)


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


def version_to_str(v):
    return '.'.join(str(x) for x in v)


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


def get_windows_version():
    candidates = [
        os.path.expandvars(r'%ProgramFiles%\Google\Chrome\Application\chrome.exe'),
        os.path.expandvars(r'%ProgramFiles(x86)%\Google\Chrome\Application\chrome.exe'),
        os.path.expandvars(r'%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"
            ])
            if out:
                v = parse_version(out)
                if v:
                    return path, v
            out = run_cmd([path, '--version'])
            if out:
                v = parse_version(out)
                if v:
                    return path, v
    return None, None


def get_macos_version():
    app = '/Applications/Google Chrome.app'
    plist = Path(app) / 'Contents' / 'Info.plist'
    if plist.exists():
        out = run_cmd(['/usr/bin/defaults', 'read', str(plist), 'CFBundleShortVersionString'])
        if out:
            v = parse_version(out)
            if v:
                return app, v
    bin_path = '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'
    if os.path.exists(bin_path):
        out = run_cmd([bin_path, '--version'])
        if out:
            v = parse_version(out)
            if v:
                return bin_path, v
    return None, None


def get_linux_version():
    cmds = [
        ['google-chrome', '--version'],
        ['google-chrome-stable', '--version'],
        ['chromium-browser', '--version'],
        ['chromium', '--version'],
    ]
    for cmd in cmds:
        out = run_cmd(cmd)
        if out:
            v = parse_version(out)
            if v:
                return ' '.join(cmd[:-1]), v
    paths = [
        '/opt/google/chrome/chrome',
        '/usr/bin/google-chrome',
        '/usr/bin/google-chrome-stable',
        '/snap/bin/chromium',
        '/usr/bin/chromium-browser',
        '/usr/bin/chromium',
    ]
    for path in paths:
        if os.path.exists(path):
            out = run_cmd([path, '--version'])
            if out:
                v = parse_version(out)
                if v:
                    return path, v
    return None, None


def main():
    system = platform.system().lower()
    source = None
    version = None

    if 'windows' in system:
        source, version = get_windows_version()
    elif 'darwin' in system:
        source, version = get_macos_version()
    elif 'linux' in system:
        source, version = get_linux_version()
    else:
        print('UNKNOWN - unsupported operating system')
        sys.exit(2)

    if not version:
        print('UNKNOWN - Google Chrome version could not be determined')
        sys.exit(2)

    verdict = 'PATCHED' if version >= MIN_SAFE else 'VULNERABLE'
    print(f'{verdict} - detected version {version_to_str(version)} from {source}; minimum safe version is {version_to_str(MIN_SAFE)}')
    sys.exit(0 if verdict == 'PATCHED' else 1)


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

If you remember one thing.

TL;DR
Monday morning, pull a fleet report for Chrome versions and find every endpoint below 149.0.7827.53; then push this through your next normal browser rollout wave, starting with high-risk users and unmanaged stragglers. Because this lands at MEDIUM, there is noisgate mitigation SLA — go straight to the 365-day remediation window and complete the actual patch rollout inside the noisgate remediation SLA of ≤365 days, but in practice this belongs in your next scheduled browser update cycle, not in backlog purgatory.

Sources

  1. Chrome Releases: Early Stable Update for Desktop
  2. Chromium source log for 149.0.7827.30..149.0.7827.53
  3. Chromium Security: Memory safety
  4. Chromium Security: Secure Architecture
  5. Canadian Centre for Cyber Security advisory AV26-544
  6. SecurityWeek: Chrome 149 Patches 429 Vulnerabilities
  7. CISA Known Exploited Vulnerabilities Catalog
  8. FIRST EPSS API for CVE-2026-11054
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.