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

Use after free in Canvas 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 master key room

CVE-2026-11136 is a use-after-free in Chrome Canvas that affects Google Chrome before 149.0.7827.53 on Linux and before 149.0.7827.53/54 on Windows and macOS. A malicious site can trigger memory corruption through crafted HTML/JavaScript and potentially achieve arbitrary code execution inside the Chrome sandboxed renderer, which matters because Chrome is ubiquitous and user browsing is the delivery path.

The raw 8.8 CVSS overstates enterprise urgency for patch scheduling. The decisive reality is that the advertised impact is inside the sandbox, not a full workstation takeover, and exploitation still needs user interaction plus a browser memory-corruption exploit that survives modern mitigations; with no KEV listing, no public PoC, and very low EPSS, this is a patch-worthy browser flaw but not a drop-everything incident.

"Real bug, real patch, but it's a sandboxed browser renderer issue with user interaction and no exploitation evidence."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Land the user on attacker-controlled content

The attacker needs a victim to load a crafted page that exercises Canvas in a way that hits the freed object. In practice this is phishing, malvertising, a compromised site, or a redirect chain. The delivery tool is just a browser-reachable HTML/JavaScript page; there is no exposed enterprise service to scan and hit directly.
Conditions required:
  • Attacker can host or inject a crafted web page
  • Victim uses vulnerable Chrome build
  • Victim reaches the page and renders it
Where this breaks in practice:
  • Requires user interaction; this is not a wormable network service bug
  • Enterprise web filtering, Safe Browsing, URL rewriting, and email security reduce delivery success
  • Chrome auto-update shrinks the vulnerable population quickly in managed fleets
Detection/coverage: Traditional vuln scanners can version-detect Chrome, but they do not validate exploitability. Web gateway, email security, and browser telemetry are better for catching delivery attempts than network perimeter scanners.
STEP 02

Shape renderer heap with JavaScript

The attacker uses JavaScript-driven heap grooming to force a stale Canvas object reference to be reused in a controlled way. This is the classic browser-exploit stage: reliability engineering, timing, and object layout matter more than the CVSS number suggests.
Conditions required:
  • Renderer can execute attacker JavaScript
  • Bug is reachable in the victim's platform/build combination
  • Exploit chain achieves stable heap layout
Where this breaks in practice:
  • Modern Chrome exploit mitigations make renderer memory corruption harder to weaponize reliably
  • Cross-version reliability is poor; attackers usually tune for exact builds
  • Crashes are more common than clean code execution for fresh browser bugs
Detection/coverage: Browser crash spikes, exploit-mitigation hits, and abnormal renderer terminations may show up in EDR or browser crash telemetry. Commodity vulnerability scanners generally have zero visibility into this stage.
STEP 03

Gain code execution in the sandboxed renderer

If the memory corruption is controlled, the attacker may execute arbitrary code, but the vendor description is explicit that this is inside a sandbox. That means the code runs in the renderer security boundary, not as unrestricted user or SYSTEM-level code on the endpoint.
Conditions required:
  • Successful weaponization of the use-after-free
  • Exploit reliability sufficient for target architecture
  • Sandbox remains the current security boundary
Where this breaks in practice:
  • Impact is constrained by the sandbox
  • Without a second vulnerability, the attacker does not get full host compromise from this CVE alone
  • Many campaigns prefer easier browser bugs with immediate sandbox escape or data theft primitives
Detection/coverage: EDR may catch suspicious child-process attempts, exploit chains, or post-exploitation actions. The CVE by itself does not provide a strong endpoint signature beyond crashes and anomalous browser behavior.
STEP 04

Attempt post-sandbox objectives

To turn renderer execution into meaningful enterprise impact, the attacker normally needs a second step: a sandbox escape, browser-to-OS pivot, credential theft within available renderer access, or session abuse. This is where real-world severity drops: the published CVE does not claim that second step.
Conditions required:
  • Useful data or reachable APIs exist from renderer context
  • Attacker has an additional exploit or abuse path
  • Defenses do not stop browser-to-host pivoting
Where this breaks in practice:
  • This step often requires another bug or separate weakness
  • MFA, EDR, application control, and OS hardening reduce blast radius
  • Enterprise compromise value varies heavily by what the user has active in-browser
Detection/coverage: This stage is where defenders usually get visibility: credential access attempts, abnormal process trees, suspicious network egress, or access-token abuse. Vulnerability scanners will miss it; EDR and identity telemetry won't.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public exploitation evidence found in the sources reviewed; no CISA KEV listing as of 2026-06-05
PoC availabilityNo public PoC or GitHub exploit repo located during review; Chromium bug remains access-restricted
EPSSUser-supplied EPSS is 0.0008; that is very low and aligns with a newly disclosed, not-yet-weaponized client-side browser bug
EPSS percentileNot verified from a primary EPSS record during this review; treat the score as directional, not the percentile
KEV statusNot listed in CISA KEV; no federal due date pressure
CVSS vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H — the important real-world bit is UI:R plus the vendor description limiting impact to inside the sandbox
Affected versionsGoogle Chrome before 149.0.7827.53 on Linux and before 149.0.7827.53/54 on Windows/macOS
Fixed versionsPatch to 149.0.7827.53 on Linux or 149.0.7827.53/54 on Windows/macOS; Chrome Early Stable shipped 2026-05-29, Stable channel announcement followed 2026-06-02
Exposure/scanning realityThis is not Internet-exposed in the Shodan/Censys sense; exposure is your endpoint/browser estate, not a server listening on a port. Asset truth comes from software inventory, browser management, and EDR version telemetry.
Disclosure and researchersDisclosed 2026-06-04 in NVD/CVE ingestion; Chrome release notes credit Jungwoo Lee (@physicube) and Wongi Lee (@_qwerty_po), reported on 2026-04-11
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to MEDIUM (5.8/10)

The biggest downward pressure is that the stated impact is code execution inside the Chrome sandbox, not a workstation-level compromise from one bug. Add user interaction, no KEV, no public weaponization, and a very low EPSS, and this lands as a broad-but-constrained browser patch rather than a top-of-queue emergency.

HIGH Affected versions and fixed versions
HIGH No-KEV / no-public-PoC status at time of review
MEDIUM Severity downgrade based on sandbox-limited impact and real-world exploit friction

Why this verdict

  • Sandbox containment cuts the blast radius: the vendor description says arbitrary code execution is *inside a sandbox*, which is materially less severe than a one-shot host compromise.
  • User interaction is mandatory: UI:R means the attacker needs the victim to render hostile content, so this is not a wormable or scan-and-smash flaw.
  • No field evidence is pushing urgency up: no KEV listing, no public PoC found, and a user-supplied EPSS of 0.0008 all point away from immediate operational exploitation.
  • Browser bugs are common; reliable chains are not: getting from a use-after-free to stable renderer RCE across enterprise builds takes exploit engineering, and many attempts will just crash Chrome.
  • Exposure is wide but shallow: Chrome is everywhere, so patch coverage matters, but the reachable population is 'users who browse' rather than 'an Internet-facing service anyone can hit anonymously at scale.'

Why not higher?

If this were paired with a sandbox escape, publicly exploited, or trivially reliable, the score would climb fast. As published, the chain stops at renderer compromise, and that missing second-stage pivot is the main reason this does not stay HIGH.

Why not lower?

This is still a real memory-corruption bug in an extremely common application. A malicious page is a plausible delivery vehicle in any large enterprise, so dismissing it as LOW or IGNORE would understate the ubiquity and potential user-level business impact.

05 · Compensating Control

What to do — in priority order.

  1. Force browser auto-update compliance — Verify your management stack is actually enforcing Chrome auto-update and relaunch behavior, because that is the cleanest way to collapse exposure. For a MEDIUM verdict there is no noisgate mitigation SLA, so use this as immediate hygiene while you work inside the 365-day remediation window.
  2. Block risky delivery paths — Harden email-link detonation, web filtering, Safe Browsing enforcement, and category-based blocks for newly registered or low-reputation domains to cut initial page loads. There is no mitigation SLA for MEDIUM, so deploy where easy and high-value rather than treating this as emergency change work.
  3. Reduce unmanaged Chrome use — Find hosts running unmanaged, stale, or user-installed Chrome outside enterprise policy and either enroll them or remove them, since these machines persist long after the managed fleet updates. With a MEDIUM verdict, do this as exposure reduction while proceeding directly toward remediation.
  4. Watch for browser crash spikes — Use EDR, crash telemetry, or browser management reporting to spot clusters of Chrome renderer crashes on vulnerable builds, which can be your earliest signal of exploit development or active targeting. For MEDIUM there is no formal mitigation deadline, but this is low-cost monitoring to keep in place until patch saturation is complete.
What doesn't work
  • A network perimeter IPS signature is not a dependable answer here, because the trigger is hostile browser content over normal web traffic and exploit specifics are likely obfuscated or encrypted.
  • MFA does not stop exploitation of the browser bug itself; it only helps if the attacker later pivots into account abuse.
  • Server-side Internet exposure scanning will not tell you who is at risk, because Chrome is an endpoint application, not an externally listening service.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your fleet tooling on Windows, macOS, or Linux. Invoke it with python3 check_cve_2026_11136.py or python3 check_cve_2026_11136.py --path "/Applications/Google Chrome.app/Contents/MacOS/Google Chrome"; no admin rights are required unless your EDR blocks process inspection.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# check_cve_2026_11136.py
# Purpose: determine whether installed Google Chrome is vulnerable to CVE-2026-11136
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

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

PATCH_LINUX = (149, 0, 7827, 53)
PATCH_WIN_MAC = (149, 0, 7827, 53)  # advisory says Windows/Mac 149.0.7827.53/54; 53 is fixed baseline

CANDIDATES = {
    'Windows': [
        r'C:\Program Files\Google\Chrome\Application\chrome.exe',
        r'C:\Program Files (x86)\Google\Chrome\Application\chrome.exe',
        os.path.expandvars(r'%LOCALAPPDATA%\Google\Chrome\Application\chrome.exe'),
    ],
    'Darwin': [
        '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
        os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
    ],
    'Linux': [
        shutil.which('google-chrome'),
        shutil.which('google-chrome-stable'),
        '/opt/google/chrome/chrome',
        '/usr/bin/google-chrome',
        '/usr/bin/google-chrome-stable',
    ],
}

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


def run_version(path):
    try:
        cp = subprocess.run([path, '--version'], capture_output=True, text=True, timeout=10)
        text = (cp.stdout or '') + ' ' + (cp.stderr or '')
        return text.strip()
    except Exception:
        return None


def discover_paths(user_path=None):
    if user_path:
        return [user_path]
    sysname = platform.system()
    vals = CANDIDATES.get(sysname, [])
    return [p for p in vals if p and os.path.exists(p)]


def compare_versions(installed, fixed):
    # returns -1 if installed < fixed, 0 if equal, 1 if installed > fixed
    if installed < fixed:
        return -1
    if installed > fixed:
        return 1
    return 0


def main():
    user_path = None
    if len(sys.argv) == 3 and sys.argv[1] == '--path':
        user_path = sys.argv[2]
    elif len(sys.argv) not in (1, 3):
        print('UNKNOWN: usage: python3 check_cve_2026_11136.py [--path /full/path/to/chrome]')
        sys.exit(2)

    sysname = platform.system()
    paths = discover_paths(user_path)
    if not paths:
        print('UNKNOWN: Google Chrome executable not found')
        sys.exit(2)

    fixed = PATCH_LINUX if sysname == 'Linux' else PATCH_WIN_MAC

    for path in paths:
        ver_out = run_version(path)
        if not ver_out:
            continue
        ver = norm_version_tuple(ver_out)
        if not ver:
            continue

        cmp_res = compare_versions(ver, fixed)
        version_str = '.'.join(str(x) for x in ver)
        fixed_str = '.'.join(str(x) for x in fixed)

        if cmp_res < 0:
            print(f'VULNERABLE: {path} version {version_str} is older than fixed baseline {fixed_str}')
            sys.exit(1)
        else:
            print(f'PATCHED: {path} version {version_str} meets or exceeds fixed baseline {fixed_str}')
            sys.exit(0)

    print('UNKNOWN: Chrome found but version could not be determined')
    sys.exit(2)

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

If you remember one thing.

TL;DR
Monday morning, treat this as a broad browser hygiene patch, not an incident-response fire drill: identify all Chrome installs below 149.0.7827.53 on Linux and below 149.0.7827.53/54 on Windows/macOS, verify auto-update is functioning, and close out unmanaged stragglers. Because this lands MEDIUM with no KEV and no active exploitation evidence, there is no noisgate mitigation SLA — go straight to the 365-day remediation window; complete the actual browser upgrade within the noisgate remediation SLA of 365 days, but in practice most enterprises should finish this far sooner through normal browser update operations.

Sources

  1. NVD CVE-2026-11136
  2. Chrome Releases: Stable Channel Update for Desktop (2026-06-02)
  3. Chrome Releases: Early Stable Update for Desktop (2026-05-29)
  4. Chromium issue 501646327
  5. CISA Known Exploited Vulnerabilities Catalog
  6. FIRST EPSS overview
  7. FIRST EPSS API documentation
  8. CIRCL Vulnerability Lookup entry
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.