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

Use after free in Input in Google Chrome prior to 149

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

This is less a front-door break-in than a second lock failing after the burglar is already in the hallway

CVE-2026-11293 is a use-after-free in Chrome's Input component affecting desktop Chrome before 149.0.7827.53 on Linux and before 149.0.7827.53/54 on Windows and macOS. The bug class and published description point to a sandbox escape outcome from a malicious web page, which means the endgame is breaking out of Chrome's renderer isolation and reaching more privileged browser or host functionality.

The vendor's CRITICAL 9.6 score is too hot for enterprise patch triage because CVSS is scoring the *technical end state*, not the real-world attack chain. In practice, sandbox-escape bugs are usually second-stage browser exploit components: they matter a lot when paired with a renderer compromise, but by themselves they are not the same thing as a reliable single-bug drive-by RCE, and the current public signal shows no KEV listing, no public exploit, and extremely low EPSS.

"Treat this like a chain component, not a one-click internet-to-kernel catastrophe."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Lure the target into hostile web content

The attacker delivers a crafted HTML/JavaScript page through phishing, malvertising, SEO poisoning, or a compromised site. This gets untrusted content into the victim's Chrome renderer, which is the only realistic place a web attacker starts.
Conditions required:
  • Target uses vulnerable Chrome/Chromium build
  • Target browses attacker-controlled or attacker-influenced content
  • JavaScript or equivalent active content is allowed
Where this breaks in practice:
  • User interaction is required (UI:R)
  • Enterprise filtering, browser reputation controls, and safe browsing routinely kill commodity delivery paths
  • A meaningful fraction of managed Chrome fleets auto-update within days
Detection/coverage: Email gateways, secure web gateways, Safe Browsing, and DNS/web filtering may catch the delivery stage, but vulnerability scanners do not meaningfully see this client-side condition.
STEP 02

Gain renderer-side control or a reliable browser primitive

For a sandbox escape to matter in real operations, the attacker typically needs a renderer foothold first or some equivalent content-triggered control primitive. Public details are still restricted, so this prerequisite is an inference from the bug class and the 'sandbox escape' wording, not a confirmed exploit recipe.
Conditions required:
  • Attacker can drive complex browser state from the malicious page
  • A renderer-side exploitation primitive exists or can be paired in-chain
  • Exploit reliability is high enough across the target's OS/Chrome build
Where this breaks in practice:
  • This is the biggest downward pressure on severity: it likely assumes a prior compromise stage inside the browser
  • Modern exploit mitigations, heap hardening, sandboxing, CFG/CET/PAC, and crash telemetry reduce reliability
  • Public issue details remain embargoed/restricted
Detection/coverage: EDR may only see renderer crashes, tab instability, or unusual child-process behavior; signature-based coverage is usually poor before exploit details go public.
STEP 03

Trigger the Input use-after-free

The exploit abuses object lifetime in Input so stale memory gets reused after free, creating a path to corrupt control flow or privileged state. If reliable, this turns renderer-originated influence into a boundary-crossing primitive aimed at the browser or host side of Chrome's trust model.
Conditions required:
  • Precise heap grooming and object lifetime control
  • Reachability of the vulnerable Input code path on the target platform
  • Unpatched version prior to 149.0.7827.53/54
Where this breaks in practice:
  • Memory-corruption exploitation reliability varies sharply by OS, allocator state, and build flags
  • Fleet diversity across Windows, macOS, Linux, and browser channels makes one-size-fits-all weaponization harder
  • Chrome's own security team keeps bug details restricted until adoption improves
Detection/coverage: There is no strong network signature. Best signals are browser crash spikes, unusual relaunch patterns, suspicious child-process trees, and endpoint telemetry around Chrome process ancestry.
STEP 04

Escape the sandbox and act as the logged-on user

If the bug is exploited successfully, the attacker breaks the renderer containment model and can act with the logged-on user's local permissions. That is serious on endpoints with accessible data, tokens, password stores, or follow-on tooling, but it is still a workstation compromise path, not a direct enterprise-wide server-side blast radius.
Conditions required:
  • Successful sandbox bypass
  • Valuable user context or reachable post-exploitation objectives on the host
  • No additional control blocks from EDR or application control
Where this breaks in practice:
  • Impact is generally bounded to the victim endpoint and user context unless followed by more post-exploitation
  • EDR, browser isolation, and privilege management can still contain follow-on behavior
  • This is not internet-scale perimeter exposure like an unauthenticated appliance RCE
Detection/coverage: Post-exploitation is where defenders usually win: EDR can catch token theft, suspicious child processes, credential-store access, LOLBin abuse, or lateral movement attempts.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public exploitation evidence found as of 2026-06-05; not KEV-listed.
Proof-of-concept availabilityNo public GitHub PoC or exploit repo located in current open-source search results; Chromium issue 502362260 remains restricted, which is normal for fresh browser memory-corruption bugs.
EPSS0.00068 (~0.068%) from the prompt intel — extremely low near-term exploitation probability relative to typical emergency patch drivers.
KEV statusNot listed in the CISA Known Exploited Vulnerabilities catalog as checked after disclosure.
CVSS vector reality checkCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H captures severe *possible impact*, but it overstates single-bug operational risk because UI:R already narrows reach and a sandbox-escape outcome usually implies a multi-stage browser chain.
Affected versionsDesktop Chrome prior to 149.0.7827.53 (Linux) and prior to 149.0.7827.53/54 (Windows/Mac) per Google's release post and Canada's advisory.
Fixed versionsGoogle patched in 149.0.7827.53/54 for desktop; Android 149.0.7827.59 inherits the same security fixes as the desktop train. Distro rebuilds such as openSUSE Chromium 149.0.7827.53 also carry the fix set.
Scanning / exposure dataShodan/Censys/FOFA/GreyNoise are basically non-signals here because this is a client-side browser flaw, not a remotely fingerprintable server service. Exposure has to be measured from endpoint version inventory, not internet census.
Disclosure timelineVendor patch train published 2026-06-02; Canadian advisory followed 2026-06-03; the prompt lists public disclosure as 2026-06-05.
Reporter / bug visibilityPublic reporter attribution is not exposed in the available sources. The issue does not appear in Google's highlighted external-researcher reward list for the June 2 desktop stable post, which suggests a Google-found or non-highlighted fix — that part is an inference, not a confirmed attribution.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to MEDIUM (6.5/10)

The decisive factor is that this looks like a sandbox-escape chain component, not a proven single-bug drive-by compromise. Without active exploitation, KEV pressure, or a public reliable exploit, the vendor's CRITICAL score is pricing in the *end state* while ignoring the most important real-world friction: the likely need for prior browser compromise or equivalent renderer control.

MEDIUM Overall severity reassessment
LOW Exact exploit preconditions, because public bug details remain restricted

Why this verdict

  • Post-renderer assumption cuts hard: the public description says *sandbox escape*, which in real browser ops usually means the attacker still needs renderer-side control first. That is a compounding prerequisite and a major downgrade from vendor CVSS.
  • No exploitation pressure: there is no KEV listing, no public in-the-wild reporting, and the supplied EPSS of 0.00068 is extremely low. That is not the profile of a fleet-wide fire drill.
  • Reachable product, limited enterprise blast radius: Chrome is everywhere, so population is broad, but successful exploitation lands on a user workstation in user context. This is not an unauthenticated perimeter service that turns one internet request into mass compromise.

Why not higher?

I am not scoring this HIGH or CRITICAL because the public evidence does not show a reliable one-bug drive-by chain, active exploitation, or a KEV-grade threat signal. If later reporting shows this is directly web-reachable without a separate renderer bug, or if exploit kits start using it, the score should move up fast.

Why not lower?

I am not dropping this to LOW because browser bugs on ubiquitous endpoints still matter, and a successful sandbox escape is a real boundary break with meaningful host impact. Also, endpoint version lag is common in large fleets, so a non-trivial vulnerable population can persist even when Chrome nominally auto-updates.

05 · Compensating Control

What to do — in priority order.

  1. Force Chrome auto-update and relaunch — Use enterprise policy to verify automatic update is enabled and relaunch prompts are enforced so patched builds actually replace stale processes. For a MEDIUM verdict there is no mitigation SLA under noisgate, so treat this as normal browser hygiene and fold it into your standard browser-management cycle rather than emergency change control.
  2. Hunt for version lag, not network exposure — Query endpoint management, EDR, or software inventory for Chrome/Chromium versions below 149.0.7827.53/54 and clean up unmanaged exceptions. There is no mitigation SLA for MEDIUM, but this is the highest-value control because browser client flaws are invisible to perimeter scanners.
  3. Keep browser exploit containment on — Preserve or expand browser isolation, EDR browser child-process protection, application control, and least-privilege user context to reduce damage if a renderer-to-host chain lands. Again, no mitigation SLA applies here; implement through your normal hardening program.
What doesn't work
  • A WAF will not help; this is a client-side browser flaw, not a server request parsing issue.
  • Perimeter vulnerability scanners will not give useful coverage because there is no exposed network daemon to fingerprint; you need endpoint inventory.
  • Relying on users to manually restart browsers does not work at 10,000-host scale; Chrome can stay running for days and keep the vulnerable process image loaded.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your fleet execution tool. Invoke it with python3 check_cve_2026_11293.py on Windows, macOS, or Linux; no admin rights are required unless your endpoint controls block process execution. It auto-discovers common Chrome/Chromium binaries and prints VULNERABLE, PATCHED, or UNKNOWN.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# check_cve_2026_11293.py
# Detect vulnerable Google Chrome / Chromium versions for CVE-2026-11293
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

import os
import platform
import re
import shutil
import subprocess
import sys
from typing import List, Optional, Tuple

THRESHOLD = (149, 0, 7827, 53)
VERSION_RE = re.compile(r'(\d+)\.(\d+)\.(\d+)\.(\d+)')


def parse_version(text: str) -> Optional[Tuple[int, int, int, int]]:
    m = VERSION_RE.search(text or '')
    if not m:
        return None
    return tuple(int(x) for x in m.groups())


def run_version(cmd: List[str]) -> Optional[str]:
    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 None


def existing_paths(candidates: List[str]) -> List[str]:
    seen = []
    for p in candidates:
        if p and os.path.exists(p) and p not in seen:
            seen.append(p)
    return seen


def candidate_binaries() -> List[str]:
    system = platform.system().lower()
    cands = []

    # PATH hits first
    for name in [
        'google-chrome', 'google-chrome-stable', 'chromium', 'chromium-browser',
        'chrome', 'msedge'  # included only if org reuses script pattern; result is still versioned output
    ]:
        p = shutil.which(name)
        if p:
            cands.append(p)

    if system == 'windows':
        for env in ['ProgramFiles', 'ProgramFiles(x86)', 'LocalAppData']:
            base = os.environ.get(env)
            if not base:
                continue
            cands.extend([
                os.path.join(base, 'Google', 'Chrome', 'Application', 'chrome.exe'),
                os.path.join(base, 'Chromium', 'Application', 'chrome.exe')
            ])
    elif system == 'darwin':
        cands.extend([
            '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
            os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
            '/Applications/Chromium.app/Contents/MacOS/Chromium',
            os.path.expanduser('~/Applications/Chromium.app/Contents/MacOS/Chromium')
        ])
    else:
        cands.extend([
            '/usr/bin/google-chrome', '/usr/bin/google-chrome-stable',
            '/usr/bin/chromium', '/usr/bin/chromium-browser',
            '/snap/bin/chromium'
        ])

    return existing_paths(cands)


def compare_versions(found: Tuple[int, int, int, int], threshold: Tuple[int, int, int, int]) -> int:
    if found < threshold:
        return -1
    if found == threshold:
        return 0
    return 1


def main() -> int:
    bins = candidate_binaries()
    if not bins:
        print('UNKNOWN: no Chrome/Chromium binary found')
        return 2

    results = []
    for b in bins:
        out = run_version([b, '--version'])
        ver = parse_version(out or '')
        if ver:
            results.append((b, ver, out.strip()))

    if not results:
        print('UNKNOWN: Chrome/Chromium found but version could not be determined')
        return 2

    vulnerable = []
    patched = []
    for path, ver, raw in results:
        cmpv = compare_versions(ver, THRESHOLD)
        item = {'path': path, 'version': '.'.join(map(str, ver)), 'raw': raw}
        if cmpv < 0:
            vulnerable.append(item)
        else:
            patched.append(item)

    if vulnerable:
        print('VULNERABLE')
        for item in vulnerable:
            print(f"{item['path']} -> {item['version']}")
        if patched:
            print('INFO: patched binaries also present:')
            for item in patched:
                print(f"{item['path']} -> {item['version']}")
        return 1

    print('PATCHED')
    for item in patched:
        print(f"{item['path']} -> {item['version']}")
    return 0


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

If you remember one thing.

TL;DR
Monday morning, do not treat this as an outage-grade emergency, but do pull a fleet report for Chrome/Chromium version drift and make sure auto-update plus forced relaunch policy is actually working. For this MEDIUM reassessment there is no noisgate mitigation SLA — go straight to the 365-day remediation window under the noisgate remediation SLA, but because this is a browser on user endpoints, the practical move is to absorb it in your next normal browser rollout cycle and close out stragglers rather than burn incident-response change windows.

Sources

  1. Google Chrome Stable Channel Update for Desktop
  2. Canadian Centre for Cyber Security advisory AV26-544
  3. Chromium security project page
  4. Chromium issue 502362260
  5. openSUSE Chromium 149 patchinfo
  6. CISA Known Exploited Vulnerabilities catalog
  7. FIRST EPSS program
  8. Tenable CVE entry aggregating public description and scoring
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.